idnits 2.17.1 draft-ietf-dhc-isnsoption-12.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 16. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 587. ** 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? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' scope is the entire iSNS database. If' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 20 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 471 has weird spacing: '...oviders of t...' -- 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 (July 2004) is 7196 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 section? 'RFC2119' on line 528 looks like a reference -- Missing reference section? 'ISNS' on line 184 looks like a reference -- Missing reference section? 'RFC3118' on line 531 looks like a reference -- Missing reference section? 'RFC 3723' on line 463 looks like a reference -- Missing reference section? 'RFC 3720' on line 470 looks like a reference -- Missing reference section? 'DHCP' on line 518 looks like a reference -- Missing reference section? 'RFC2026' on line 525 looks like a reference -- Missing reference section? 'RFC3667' on line 534 looks like a reference -- Missing reference section? 'RFC3668' on line 537 looks like a reference -- Missing reference section? 'RFC3720' on line 540 looks like a reference -- Missing reference section? 'RFC3723' on line 543 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Charles Monia 2 INTERNET DRAFT Josh Tseng 3 Expires: January 2005 Kevin Gibbons 4 Internet Draft McDATA 5 Corporation 6 Document: 7 Category: Standards Track July 2004 9 The IPv4 DHCP Option for the Internet Storage Name Service 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 or will be disclosed, and any of which I become aware will be 16 disclosed, in accordance with RFC 3668. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. Internet-Drafts are draft documents valid for a maximum of 22 six months and may be updated, replaced, or made obsolete by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Comments 35 Comments should be sent to the DHCP mailing list (dhcwg@ietf.org) or 36 to the authors. 38 Table of Contents 40 Status of this Memo...................................................1 41 Comments..............................................................1 42 Abstract..............................................................3 43 Conventions used in this document.....................................3 44 1. Introduction.......................................................3 45 2. iSNS Option for DHCP...............................................4 46 2.1 iSNS Functions Field..............................................5 47 2.2 Discovery Domain Access Field.....................................7 48 2.3 Administrative Flags Field........................................8 49 2.4 iSNS Server Security Bitmap.......................................9 50 3. Security Considerations...........................................10 51 4. IANA Considerations...............................................11 52 5. Normative References..............................................12 53 6. Non-Normative References..........................................12 54 7. Author's Addresses................................................13 55 8. Intellectual Property.............................................13 56 9. Full Copyright Statement..........................................13 57 10. Disclaimer of Validity...........................................13 58 11. Acknowledgement..................................................14 59 12. Expiration Notice................................................14 60 Abstract 62 This document describes the DHCP option to allow Internet Storage 63 Name Service (iSNS) clients to automatically discover the location 64 of the iSNS server through the use of DHCP for IPv4. iSNS provides 65 discovery and management capabilities for Internet SCSI (iSCSI) and 66 Internet Fibre Channel Protocol (iFCP) storage devices in an 67 enterprise-scale IP storage network. iSNS provides intelligent 68 storage management services comparable to those found in Fibre 69 Channel networks, allowing a commodity IP network to function in a 70 similar capacity as a storage area network. 72 Conventions used in this document 74 iSNS refers to the Internet Storage Name Service framework 75 consisting of the storage network model and associated services. 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 79 this document are to be interpreted as described in [RFC2119]. 81 All frame formats are in big endian network byte order. RESERVED 82 fields SHOULD be set to zero. 84 This document uses the following terms: 86 "iSNS Client" - iSNS clients are processes resident in iSCSI and 87 iFCP devices that initiate transactions with the iSNS server using 88 the iSNS Protocol. 90 "iSNS Server" - The iSNS server responds to iSNS protocol query and 91 registration messages, and initiates asynchronous notification 92 messages. The iSNS server stores information registered by iSNS 93 clients. 95 "iSCSI (Internet SCSI)" - iSCSI is an encapsulation of SCSI for a 96 new generation of storage devices interconnected with TCP/IP. 98 "iFCP (Internet Fibre Channel Protocol)" - iFCP is a gateway-to- 99 gateway protocol designed to interconnect existing Fibre Channel 100 devices using TCP/IP. iFCP maps the Fibre Channel transport and 101 fabric services to TCP/IP. 103 1. Introduction 105 The Dynamic Host Configuration Protocol for IPv4 provides a 106 framework for passing configuration information to hosts. Its 107 usefulness extends to hosts and devices using the iSCSI and iFCP 108 protocols to connect to block level storage assets over a TCP/IP 109 network. 111 The iSNS Protocol provides a framework for automated discovery, 112 management, and configuration of iSCSI and iFCP devices on a TCP/IP 113 network. It provides functionality similar to that found on Fibre 114 Channel networks, except that iSNS works within the context of an IP 115 network. iSNS thereby provides the requisite storage intelligence 116 to IP networks that are standard on existing Fibre Channel networks. 118 Existing DHCP options cannot be used to find iSNS servers for the 119 following reasons: 121 a) iSNS functionality is distinctly different from other protocols 122 using DHCP options. Specifically, iSNS provides a significant 123 superset of capabilities compared to typical name resolution 124 protocols such as DNS. It is designed to support client devices 125 that allow themselves to be configured and managed from a 126 central iSNS server 128 b) iSNS requires a DHCP option format that provides more than the 129 location of the iSNS server. The DHCP option needs to specify 130 the subset of iSNS services that may be actively used by the 131 iSNS client. 133 The DHCP option number for iSNS is used by iSCSI and iFCP devices to 134 discover the location and role of the iSNS server. The DHCP option 135 number assigned for iSNS by IANA is <>. 137 2. iSNS Option for DHCP 139 This option specifies the location of the primary and backup iSNS 140 servers and the iSNS services available to an iSNS client. 142 0 1 2 3 143 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Code = TBD | Length | iSNS Functions | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | DD Access | Administrative FLAGS | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | iSNS Server Security Bitmap | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | a1 | a2 | a3 | a4 | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | b1 | b2 | b3 | b4 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | . . . . | 156 | Additional Secondary iSNS Servers | 157 | . . . . | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1 -- iSNS Server Option 161 The iSNS Option specifies a list of IP addresses used by iSNS 162 servers. The option contains the following parameters: 164 Length: the number of bytes that follow the Length field. 166 iSNS Functions: A bitmapped field defining the functions supported 167 by the iSNS servers. The format of this field is described 168 in section 2.1. 170 Discovery Domain Access: A bit field indicating the types of iSNS 171 clients that are allowed to modify Discovery Domains. The 172 field contents are described in section 2.2. 174 Administrative Flags field: Contains the administrative settings for 175 the iSNS servers discovered through the DHCP query. The 176 contents of this field are described in section 2.3. 178 iSNS Server Security Bitmap: Contains the iSNS server security 179 settings specified in section 2.4. 181 a1...a4: Depending on the setting of the Heartbeat bit in the 182 Administrative Flags field (see section 2.3), this field 183 contains either the IP address from which the iSNS heartbeat 184 originates (see [ISNS]) or the IP address of the primary 185 iSNS server. 187 b1...b4: Depending on the setting of Heartbeat bit in the 188 Administrative Flags field (see section 2.3), this field 189 contains either the IP address of the primary iSNS server or 190 a secondary iSNS server. 192 Additional Secondary iSNS Servers: Each set of four octets specifies 193 the IP address of a secondary iSNS server. 195 The Code field through IP address field a1...a4 MUST be present in 196 every response to the iSNS query, hence the Length field has a 197 minimum value of 14. 199 If the Heartbeat bit is set in the Administrative Flags field (see 200 section 2.3), then b1...b4 MUST also be present. In this case, the 201 minimum value of the Length field is 18. 203 The inclusion of Additional Secondary iSNS Servers in the response 204 MUST be indicated by increasing the Length field accordingly. 206 2.1 iSNS Functions Field 208 The iSNS Functions Field defines the iSNS server's operational role 209 (i.e., how the iSNS server is to be used). The iSNS server's role 210 can be as basic as providing simple discovery information, or as 211 significant as providing IKE/IPSec security policies and 212 certificates for the use of iSCSI and iFCP devices. The format of 213 the iSNS Functions field is shown in Figure 2: 215 0 1 1 216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | RESERVED |S|A|E| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2 -- iSNS Functions Field 222 Bit field Significance 223 --------- ------------ 224 15 Function Fields Enabled 225 14 DD-Based Authorization 226 13 Security Policy Distribution 228 iSNS Functions Field definitions: 230 Function Fields This bit specifies the validity of the 231 Enabled: remaining iSNS Function fields. If set to 232 one, then the contents of all other iSNS 233 Function fields are valid. If set to zero, 234 then the contents of all other iSNS 235 Function fields MUST be ignored. 237 DD-based Indicates whether or not devices in a 238 Authorization: common Discovery Domain (DD) are implicitly 239 authorized to access one another. Although 240 Discovery Domains control the scope of 241 device discovery, they do not necessarily 242 indicate whether or not a domain member is 243 authorized to access discovered devices. 244 If this bit is set to one, then devices in 245 a common Discovery Domain are automatically 246 allowed access to each other (if 247 successfully authenticated). If this bit 248 is set to zero, then access authorization 249 is not implied by domain membership and 250 must be explicitly performed by each 251 device. In either case, devices not in a 252 common discovery domain are not allowed to 253 access each other. 255 Security Policy Indicates whether the iSNS client is to 256 Distribution: download and use the security policy 257 configuration stored in the iSNS server. 258 If set to one, then the policy is stored in 259 the iSNS server and must be used by the 260 iSNS client for its own security policy. 261 If set to zero, then the iSNS client must 262 obtain its security policy configuration by 263 other means. 265 2.2 Discovery Domain Access Field 267 The format of the DD Access bit field is shown in Figure 3: 269 0 1 1 1 1 1 1 270 0 ... 9 0 1 2 3 4 5 271 +---+---+---+---+---+---+---+---+---+ 272 | RESERVED | if| tf| is| ts| C | E | 273 +---+---+---+---+---+---+---+---+---+ 274 Figure 3 -- Discovery Domain Access Field 276 Bit field Significance 277 --------- ------------ 278 15 Enabled 279 14 Control Node 280 13 iSCSI Target 281 12 iSCSI Initiator 282 11 iFCP Target Port 283 10 iFCP Initiator Port 285 Discovery Domain Access Field Definitions: 287 Enabled: This bit specifies the validity of the 288 remaining DD Access bit fields. If this 289 bit is set to one, then the contents of 290 the remainder of the DD Access field are 291 valid. If this bit is set to zero, then 292 the contents of the remainder of this 293 field MUST be ignored. 295 Control Node: Specifies whether the iSNS server allows 296 Discovery Domains to be added, modified 297 or deleted by means of Control Nodes. If 298 set to one, then Control Nodes are 299 allowed to modify the Discovery Domain 300 configuration. If set to zero, then 301 Control Nodes are not allowed to modify 302 Discovery Domain configurations. 304 iSCSI Target, These bits determine whether the 305 iSCSI Initiator, respective registered iSNS client 306 iFCP Target Port, (determined by iSCSI Node Type or iFCP 307 iFCP Initiator Port Role) is allowed to add, delete, or 308 Port: modify Discovery Domains. If set to 309 one, then modification by the specified 310 client type is allowed. If set to zero, 311 then modification by the specified 312 client type is not allowed. 314 (A node may implement multiple node 315 types.) 317 2.3 Administrative Flags Field 319 The format of the Administrative Flags bit field is shown in 320 Figure 4: 322 0 1 1 323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | RESERVED |D|M|H|E| 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Figure 4 -- Administrative Flags 329 Bit Field Significance 330 --------- ------------ 331 15 Enabled 332 14 Heartbeat 333 13 Management SCNs 334 12 Default Discovery Domain 336 Administrative Flags Field definitions: 338 Enabled: Specifies the validity of the remainder 339 of the Administrative Flags field. If 340 set to one, then the contents of the 341 remaining Administrative Flags are 342 valid. If set to zero, then the 343 remaining contents MUST be ignored, 344 indicating that iSNS administrative 345 settings are obtained through means 346 other than DHCP. 348 Heartbeat: Indicates whether the first IP address 349 is the multicast address to which the 350 iSNS heartbeat message is sent. If set 351 to one, then a1-a4 contains the 352 heartbeat multicast address and b1-b4 353 contains the IP address of the primary 354 iSNS server, followed by the IP 355 address(es) of any backup servers (see 356 Figure 1). If set to zero, then a1-a4 357 contains the IP address of the primary 358 iSNS server, followed by the IP 359 address(es) of any backup servers. 361 Management SCNs: Indicates whether control nodes are 362 authorized to register to receive 363 Management State Change Notifications 364 (SCN's). Management SCN's are a special 365 class of State Change Notification whose 366 scope is the entire iSNS database. If 367 set to one, then control nodes are 368 authorized to register to receive 369 Management SCN's. If set to zero, then 370 control nodes are not authorized to 371 receive Management SCN's (although they 372 may receive normal SCN's). 374 Default Discovery Indicates whether a newly registered 375 Domain: device that is not explicitly placed 376 into a Discovery Domain (DD) and 377 Discovery Domain Set (DDS) should be 378 automatically placed into a default DD 379 and DDS. If set to one, then a default 380 DD shall contain all devices in the iSNS 381 database that have not been explicitly 382 placed into a DD by an iSNS client. If 383 set to zero, then devices not explicitly 384 placed into a DD are not members of any 385 DD. 387 2.4 iSNS Server Security Bitmap 389 The format of the iSNS server security Bitmap field is shown in 390 Figure 5. If valid, this field communicates to the DHCP client the 391 security settings that are required to communicate with the 392 indicated iSNS server. 394 0 1 2 3 395 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | RESERVED |T|X|P|A|M|S|E| 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 5 -- iSNS Server Security Bitmap 401 Bit Field Significance 402 --------- ---------------- 403 31 Enabled 404 30 IKE/IPSec 405 29 Main Mode 406 28 Aggressive Mode 407 27 PFS 408 26 Transport Mode 409 25 Tunnel Mode 411 iSNS Server Security Bitmap definitions: 413 Enabled This bit specifies the validity of the 414 remainder of the iSNS server security 415 bitmap. If set to one, then the contents 416 of the remainder of the field are valid. 417 If set to zero, then the contents of the 418 rest of the field are undefined and MUST 419 be ignored. 421 IKE/IPSec 1 = IKE/IPSec enabled; 0 = IKE/IPSec 422 disabled. 424 Main Mode 1 = Main Mode enabled; 0 = Main Mode 425 disabled. 427 Aggressive Mode 1 = Aggressive mode enabled; 0 = 428 Aggressive mode disabled. 430 PFS 1 = PFS enabled; 0 = PFS disabled. 432 Transport Mode 1 = Transport mode preferred; 0 = No 433 preference. 435 Tunnel Mode 1 = Tunnel mode preferred; 0 = No 436 preference. 438 If IKE/IPSec is disabled, this indicates that the Internet Key 439 Exchange (IKE) Protocol is not available to configure IPSec keys for 440 iSNS sessions to this iSNS server. It does not necessarily preclude 441 other key exchange methods (e.g., manual keying) from establishing 442 an IPSec security association for the iSNS session. 444 If IKE/IPsec is enabled, an implementation SHALL enable: 446 a) One of Main Mode or Aggressive Mode but not both and 448 b) One of Transport Mode or Tunnel Mode but not both. 450 3. Security Considerations 452 The DHCP Authentication security option as specified in [RFC3118] 453 to protect the iSNS option may present a problem due to the limited 454 implementation and deployment of the DHCP authentication option. 455 The IPSec security mechanisms for iSNS itself are specified in 456 [iSNS] to provide confidentiality when sensitive information is 457 distributed via iSNS. See the Security Considerations section of 458 [iSNS] for details and specific requirements for implementation of 459 IPSec. 461 In addition,[iSNS] describes an authentication block that provides 462 message integrity for multicast or broadcast iSNS messages (i.e. for 463 heartbeat/discovery messages only). See [RFC 3723] for further 464 discussion of security for these protocols. 466 If no sensitive information, as described in [iSNS], is being 467 distributed via iSNS, and an Entity is discovered via iSNS, 468 authentication and authorization are handled by the IP Storage 469 protocols whose endpoints are discovered via iSNS, specifically iFCP 470 [iFCP] and iSCSI [RFC 3720]. It is the responsibility of the 471 providers of these services to ensure that an inappropriately 472 advertised or discovered service does not compromise their security. 474 When no security is used, there is a risk of distribution of false 475 discovery information (e.g., via the iSNS DHCP option identifying a 476 false iSNS server that distributes the false discovery information). 477 The primary countermeasure for this risk is authentication. When 478 this risk is a significant concern, IPsec SAs SHOULD be used for IP 479 Storage protocol (iSCSI and iFCP) traffic subject to this risk to 480 ensure that such traffic only flows between endpoints that have 481 participated in IKE authentication. For example, if an attacker 482 distributes discovery information falsely identifying an iSCSI 483 endpoint, that endpoint will lack the secret information necessary 484 to successfully complete IKE authentication, and hence will be 485 prevented from falsely sending or receiving iSCSI traffic. When this 486 risk of false discovery information is a significant concern and 487 IPSec is implemented for iSNS, IPSec SAs SHOULD also be used for 488 iSNS traffic to prevent use of a false iSNS server rather than 489 relying only on the IP Storage protocols to detect false discovery 490 information. 492 There remains a risk of a denial of service attack based on repeated 493 use of false discovery information that will cause initiation of IKE 494 negotiation. The countermeasures for this are administrative 495 configuration of each iSNS and IP Storage (iSCSI and FCIP) Entity to 496 limit the peers that it is willing to communicate with (i.e., by IP 497 address range and/or DNS domain), and maintenance of a negative 498 authentication cache to avoid repeatedly contacting an iSNS Entity 499 that fails to authenticate. These three measures (i.e., IP address 500 range limits, DNS domain limits, negative authentication cache) MUST 501 be implemented for IP Storage (iSCSI and iFCP) protocols and iSNS 502 Entities. For iSNS, these requirements apply only when this DHCP 503 option is used, and in addition, the negative authentication cache 504 requirement applies only when IPSec support is implemented for iSNS, 505 as a negative authentication cache is of no value in the absence of 506 authentication. 508 4. IANA Considerations 510 In accordance with the policy defined in [DHCP], IANA has assigned a 511 value of TBD for this option. 513 There are no other IANA-assigned values defined by this 514 specification. 516 5. Normative References 518 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 519 2131, Bucknell University, March 1997. 521 [iSNS] Tseng, J. et al., "iSNS - Internet Storage Name 522 Service", Internet draft (work in progress), draft-ietf- 523 ips-isns-12.txt, August 2002 525 [RFC2026] Bradner, S., "The Internet Standards Process -- 526 Revision 3", BCP 9, RFC 2026, October 1996 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997 531 [RFC3118] Arbaugh, W., Droms, R., "Authentication for DHCP 532 Messages", RFC 3118, June 2001 534 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 535 RFC 3667, February 2004 537 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 538 Technology", BCP 79, RFC 3668, February 2004 540 [RFC3720] Satran, J., et al., "Internet Small Computer Systems 541 Interface (iSCSI)", RFC 3720, April 2004 543 [RFC3723] Aboba, B., et al., "Securing Block Storage Protocols 544 over IP", RFC 3723, April 2004 546 6. Non-Normative References 548 [iFCP] Monia, C., et al., "iFCP - A Protocol for Internet Fibre 549 Channel Storage Networking", Internet draft (work in 550 progress), draft-ietf-ips-ifcp-13.txt, May 2002 552 7. Author's Addresses 554 Kevin Gibbons, 555 Charles Monia, 556 Josh Tseng 558 McDATA Corporation 559 3850 North First Street 560 San Jose, CA 95134-1702 561 Phone: (408) 519-3700 562 Email: charles.monia@mcdata.com 563 joshtseng@yahoo.com 564 kevin.gibbons@mcdata.com 566 8. Intellectual Property 568 The IETF takes no position regarding the validity or scope of any 569 Intellectual Property Rights or other rights that might be claimed to 570 pertain to the implementation or use of the technology described in this 571 document or the extent to which any license under such rights might or 572 might not be available; nor does it represent that it has made any 573 independent effort to identify any such rights. Information on the 574 procedures with respect to rights in RFC documents can be found in BCP 78 575 and BCP 79. 577 Copies of IPR disclosures made to the IETF Secretariat and any assurances 578 of licenses to be made available, or the result of an attempt made to 579 obtain a general license or permission for the use of such proprietary 580 rights by implementers or users of this specification can be obtained 581 from the IETF on-line IPR repository at http://www.ietf.org/ipr. 583 The IETF invites any interested party to bring to its attention any 584 copyrights, patents or patent applications, or other proprietary rights 585 that may cover technology that may be required to implement this 586 standard. Please address the information to the IETF at ietf- 587 ipr@ietf.org. 589 9. Full Copyright Statement 591 Copyright (C) The Internet Society July 2004. This document is subject to 592 the rights, licenses and restrictions contained in BCP 78, and except as 593 set forth therein, the authors retain all their rights. 595 10. Disclaimer of Validity 597 This document and the information contained herein are provided on an "AS 598 IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS 599 SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 600 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 601 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 602 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 603 FITNESS FOR A PARTICULAR PURPOSE. 605 Internet-Drafts are working documents of the Internet Engineering Task 606 Force (IETF), its areas, and its working groups. Note that other groups 607 may also distribute working documents as Internet-Drafts. 609 Internet-Drafts are draft documents valid for a maximum of six months and 610 may be upated, replaced, or obsoleted by other documents at any time. It 611 is inappropriate to use Internet-Drafts as reference material or to cite 612 them other than a "work in progress." 614 The list of current Internet-Drafts can be accessed at 615 http://www.ietf.org/1id-abstracts.html 617 The list of Internet-Draft Shadow Directories can be accessed at 618 http://www.ietf.org/shadow.html 620 11. Acknowledgement 622 Funding for the RFC Editor function is currently provided by the Internet 623 Society. 625 12. Expiration Notice 627 This Internet-Draft expires in January 2005.