idnits 2.17.1 draft-ietf-ips-iscsi-name-ext-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 329. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 335. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document updates RFC3720, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2004) is 7187 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3720' is mentioned on line 188, but not defined ** Obsolete undefined reference: RFC 3720 (Obsoleted by RFC 7143) == Unused Reference: 'RFC 3667' is defined on line 248, but no explicit reference was found in the text == Unused Reference: 'RFC 3668' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC 3720' is defined on line 254, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3720 (Obsoleted by RFC 7143) -- Possible downref: Non-RFC (?) normative reference: ref. 'FC-FS' Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage Working Group 3 Internet Draft M. Krueger 4 M. Chadalapaka 5 R. Elliott 6 Document: Hewlett-Packard 7 draft-ietf-ips-iscsi-name-ext-05.txt Corp. 9 Updates: 3720 11 Expires: January 2005 August 2004 13 T11 Network Address Authority (NAA) naming format for iSCSI Node 14 Names 16 Status of this Memo 18 By submitting this Internet-Draft, we certify that any applicable 19 patent or other IPR claims of which we are aware have been 20 disclosed, and any of which we become aware will be disclosed, in 21 accordance with RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other 30 documents at any time. It is inappropriate to use Internet- 31 Drafts as reference material or to cite them other than as "work 32 in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt . 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html . 40 This Internet-Draft will expire on January 30, 2005. 42 Abstract 44 Internet Small Computer Systems Interface (iSCSI) is a SCSI 45 transport protocol that maps the SCSI family of protocols onto 46 TCP/IP. This document defines an additional iSCSI node name type 47 format to enable use of the "Network Address Authority" (NAA) 48 world wide naming format defined by InterNational Committee for 49 Information Technology Standards (INCITS) T11 - Fibre Channel 50 (FC) protocols and used by Serial Attached SCSI (SAS). This 51 document updates RFC 3720. 53 Table of Contents 55 1. Introduction...................................................2 56 2. Background.....................................................2 57 3. Motivation.....................................................3 58 4. iSCSI NAA Name Structure.......................................4 59 4.1 Type "naa." - Network Address Authority....................4 60 5. Terminology....................................................5 61 5.1 IQN........................................................5 62 5.2 SRP........................................................5 63 5.3 SAS........................................................5 64 5.4 NAA........................................................5 65 5.5 InfiniBand.................................................5 66 5.6 INCITS.....................................................5 67 5.7 T10........................................................5 68 5.8 T11........................................................5 69 6. Security Considerations........................................6 70 7. IANA Considerations............................................6 71 8. References.....................................................6 72 8.1 Normative References.......................................6 73 8.2 Informative References.....................................6 74 9. Authors' Addresses.............................................7 75 10. Full Copyright Statement......................................8 76 11. Intellectual Property Statement...............................8 78 1. Introduction 80 This document discusses the motivation for adding an NAA type 81 format as an iSCSI node name format and defines this format in 82 accordance with the iSCSI naming conventions [RFC3720]. Defining 83 this format will enable SCSI storage devices containing both 84 iSCSI ports and SAS ports to use the same NAA-based SCSI device 85 name. 87 2. Background 89 To date, there are a number of networked transports providing 90 port abstractions to the SCSI protocol. These transports all 91 incorporate some form of world-wide unique name construction 92 format. The following table summarizes the current protocols and 93 their name formats. 95 SCSI transport protocol Name Format 96 ----------------------------------------------- 97 | | EUI-64| NAA |IQN | 98 |----------------------------|-------|-----|----| 99 | iSCSI (Internet SCSI) | X | | X | 100 |----------------------------|-------|-----|----| 101 | FCP (Fibre Channel) | | X | | 102 |----------------------------|-------|-----|----| 103 | SAS (Serial Attached SCSI) | | X | | 104 |----------------------------|-------|-----|----| 105 | SRP (for InfiniBand) | X | | | 106 ----------------------------------------------- 108 The INCITS T11 Framing and Signaling Specification [FC-FS] 109 defines a format called the Network Address Authority (NAA) 110 format for constructing worldwide unique identifiers using 111 various identifier registration authorities. This identifier 112 format is used by the Fibre Channel and SAS SCSI transport 113 protocols. Since most existing networked SCSI ports today are 114 either FC or SAS, the NAA format is the most commonly used 115 identifier format for SCSI transports. 117 3. Motivation 119 If iSCSI included a naming format that allowed direct 120 representation of a NAA-format name, it would facilitate 121 construction of a target device name that translates easily 122 across multiple namespaces for a SCSI storage device containing 123 ports served by different transports. 125 This document defines an NAA type iSCSI naming format so that one 126 NAA identifier can be assigned as the basis for the SCSI device 127 name for a SCSI target with both SAS ports and iSCSI ports. 129 INCITS T10 SCSI has defined a string format SCSI target device 130 name in [SPC3] that is reported in the VPD page 83 device 131 identifier page. [SAM3] specifies that a SCSI device shall have 132 no more than one (i.e., zero or one) SCSI device name in the SCSI 133 name string format regardless of the number of SCSI transport 134 protocols supported by the SCSI device. Addition of the INCITS 135 T11-defined NAA format as a defined type for iSCSI device names 136 would make the iSCSI device naming format more consistent across 137 all current SCSI networked transports which define an NAA format 138 SCSI device name, facilitating the creation of SCSI device names 139 that are transport-independent. This would also contribute to 140 the creation of LU names based on this SCSI device name. 142 4. iSCSI NAA Name Structure 144 This document defines an additional iSCSI name type: 146 type "naa." - the remainder of the string is an INCITS T11 147 defined Network Address Authority identifier in 148 ASCII-encoded hexadecimal. 150 4.1 Type "naa." - Network Address Authority 152 [FC-FS] defines a format for constructing globally unique 153 identifiers referred to as the Network Address Authority (NAA) 154 format. 156 The iSCSI NAA name format is "naa." followed by an NAA identifier 157 represented in ASCII-encoded hexadecimal digits. 159 Example iSCSI name with a 64-bit NAA value: 161 Type NAA identifier (ASCII-encoded hexadecimal) 162 +--++--------------+ 163 | || | 165 naa.52004567BA64678D 167 Example iSCSI name with a 128-bit NAA value: 169 Type NAA identifier (ASCII-encoded hexadecimal) 170 +--++------------------------------+ 171 | || | 173 naa.62004567BA64678D0123456789ABCDEF 175 The iSCSI NAA name format might be used in an implementation 176 where the infrastructure for generating NAA worldwide unique 177 names is already in place because the device contains both SAS 178 and iSCSI SCSI ports. 180 The NAA name formatted in an ASCII-hexadecimal representation has 181 a maximum size of 32 characters (128 bit NAA format) - as a 182 result there is no issue with this name format exceeding the 183 maximum size for iSCSI node names. 185 5. Terminology 186 5.1 IQN 187 iSCSI qualified name, an identifier format defined by the iSCSI 188 protocol [RFC3720]. 190 5.2 SRP 191 SCSI RDMA Protocol. SRP defines a SCSI protocol mapping onto the 192 InfiniBand (tm) Architecture and/or functionally similar cluster 193 protocols [SRP]. 195 5.3 SAS 196 Serial Attached SCSI. The Serial Attached SCSI (SAS) standard 197 contains both a physical Layer that is compatible with Serial ATA 198 and protocols for transporting SCSI commands to SAS devices and 199 for transporting ATA commands to SATA devices [SAS]. 201 5.4 NAA 202 Network Address Authority - a naming format defined by the INCITS 203 T11 Fibre Channel protocols [FC-FS]. 205 5.5 InfiniBand 206 An I/O architecture intended to replace PCI and address high 207 performance server interconnect [IB]. 209 5.6 INCITS 210 InterNational Committee of Information Technology Standards is 211 the primary U.S. focus of standardization in the field of 212 Information and Communications Technologies (ICT), encompassing 213 storage, processing, transfer, display, management, organization, 214 and retrieval of information. As such, INCITS also serves as 215 ANSI's Technical Advisory Group for ISO/IEC Joint Technical 216 Committee 1. JTC 1 is responsible for International 217 standardization in the field of Information Technology. See 218 www.incits.org 220 5.7 T10 221 A technical committee within INCITS responsible for I/O 222 Interfaces, especially SCSI, SCSI-2, and SCSI-3 including SPI-2 223 (Fast-40 or Ultra2 SCSI), Low Voltage Differential (LVD), SPI-3 224 (Ultra3 SCSI or Ultra160), SPI-4 (Ultra320), SPI-5 (Ultra640), 225 Serial Attached SCSI (SAS). See www.t10.org 227 5.8 T11 228 A technical committee within INCITS responsible for Device Level 229 Interfaces. T11 (previously known as X3T9.3) has been producing 230 interface standards for high-performance and mass storage 231 applications. See www.t11.org 233 6. Security Considerations 235 This iSCSI name format does not introduce any new security 236 concerns for the iSCSI protocol beyond the other iSCSI naming 237 formats. Please refer to RFC 3720, section 8 for information on 238 the security considerations for the iSCSI protocol. 240 7. IANA Considerations 242 This document has no actions for IANA. 244 8. References 246 8.1 Normative References 248 [RFC 3667] Bradner, S., Ed, "IETF Rights in Contributions", BCP 249 78, RFC 3667, February 2004. 251 [RFC 3668] Bradner, S., Ed., "Intellectual Property Rights in 252 IETF Technology", BCP 79, RFC 3668, February 2004. 254 [RFC 3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, 255 M., Zeidner, E., "Internet Small Computer Systems 256 Interface (iSCSI)", RFC 3720, April 2004. 258 [FC-FS] INCITS 373:2003, Fibre Channel Framing and Signaling 259 Interface (FC-FS). 261 8.2 Informative References 263 [SPC3] T10/1416-D, SCSI Primary Commands - 3 (SPC-3). 265 [SAM3] T10/1561-D, SCSI Architecture Model - 3 (SAM-3). 267 [IB] InfiniBand{tm} Architecture Specification, Vol. 1, 268 Rel. 1.0.a, InfiniBand Trade Association 269 (www.infinibandta.org). 271 [SRP] INCITS.365:2002, SCSI RDMA Protocol (SRP). 273 [SAS] INCITS.376:2003, Serial Attached SCSI (SAS). 275 9. Authors' Addresses 277 Marjorie Krueger 278 Hewlett-Packard Company 279 8000 Foothills Blvd. 280 Roseville, CA 95747-5668, USA 281 E-mail: marjorie_krueger@hp.com 283 Mallikarjun Chadalapaka 284 Hewlett-Packard Company 285 8000 Foothills Blvd. 286 Roseville, CA 95747-5668, USA 287 E-mail: cbm@rose.hp.com 289 Rob Elliott 290 Hewlett-Packard Company 291 MC 140801 292 PO Box 692000 293 Houston, TX 77269-2000 USA 294 E-mail: elliott@hp.com 296 10. Full Copyright Statement 298 Copyright (C) The Internet Society (2004). This document is 299 subject to the rights, licenses and restrictions contained in BCP 300 78, and except as set forth therein, the authors retain all their 301 rights. 303 This document and the information contained herein are provided 304 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 305 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 306 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 307 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 308 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 309 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 310 FOR A PARTICULAR PURPOSE. 312 11. Intellectual Property Statement 314 The IETF takes no position regarding the validity or scope of 315 any Intellectual Property Rights or other rights that might be 316 claimed to pertain to the implementation or use of the 317 technology described in this document or the extent to which any 318 license under such rights might or might not be available; nor 319 does it represent that it has made any independent effort to 320 identify any such rights. Information on the procedures with 321 respect to rights in RFC documents can be found in BCP 78 and 322 BCP 79. 324 Copies of IPR disclosures made to the IETF Secretariat and any 325 assurances of licenses to be made available, or the result of an 326 attempt made to obtain a general license or permission for the 327 use of such proprietary rights by implementers or users of this 328 specification can be obtained from the IETF on-line IPR 329 repository at http://www.ietf.org/ipr. 331 The IETF invites any interested party to bring to its attention 332 any copyrights, patents or patent applications, or other 333 proprietary rights that may cover technology that may be required 334 to implement this standard. Please address the information to 335 the IETF at ietf-ipr@ietf.org. 337 Acknowledgment 339 Funding for the RFC Editor function is currently provided by the 340 Internet Society.