idnits 2.17.1 draft-ietf-ips-iscsi-boot-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 516 has weird spacing: '... to pertain...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The software stage SHOULD not be involved in a secure iSCSI boot process as this would add the additional complexity of trying to secure the process of loading the software necessary to run the later stages of iSCSI boot. It is therefore assumed that all the necessary software is resident on the iSCSI boot client. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The mechanism for securing the iSCSI boot process SHOULD not be enabled by default so as to avoid the configuration, deployment and provisioning requirements of the secure boot process. -- 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 (27 February 2003) is 7722 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) == Unused Reference: 'Bradner96' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'Bradner97' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'Droms93' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'Droms97' is defined on line 419, but no explicit reference was found in the text == Unused Reference: 'Droms01' is defined on line 422, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bakke02' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bound02' ** Obsolete normative reference: RFC 1497 (ref. 'Reynolds93') (Obsoleted by RFC 1533) -- Possible downref: Non-RFC (?) normative reference: ref. 'Satran02' ** Obsolete normative reference: RFC 2279 (ref. 'Yergeau98') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 1532 (ref. 'Wimer93') (Obsoleted by RFC 1542) -- Obsolete informational reference (is this intentional?): RFC 783 (ref. 'Sollins81') (Obsoleted by RFC 1350) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IP Storage Working Group Prasenjit Sarkar 3 Internet Draft IBM 4 Document: draft-ietf-ips-iscsi-boot-09.txt Duncan Missimer 5 Category: Standards Track Rhapsody Networks 6 Constantin Sapuntzakis 7 Stanford University 8 27 February 2003 10 Bootstrapping Clients using the iSCSI Protocol 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or made obsolete by other documents at 22 any time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as "work in progress." The list 24 of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft 26 Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 The words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 31 documents are to be interpreted as described in RFC 2119. 33 Abstract 35 iSCSI is a proposed transport protocol for SCSI that operates on top 36 of TCP. This memo describes a standard mechanism to enable clients 37 to bootstrap themselves using the iSCSI protocol. The goal of this 38 standard is to enable iSCSI boot clients to obtain the information to 39 open an iSCSI session with the iSCSI boot server. 41 1. Introduction 43 The Small Computer Systems Interface (SCSI) is a popular family of 44 protocols for communicating with I/O devices, especially storage 45 devices. SCSI can be characterized as a request/response messaging 46 protocol with a standard architecture and componentized command sets 47 for different device classes. 49 Standards Track iSCSI BootStrapping Draft 27 February 2003 51 iSCSI is a proposed transport protocol for SCSI that operates on top 52 of TCP. The role of iSCSI is necessitated by the evolution of the 53 system interconnect from a shared bus to a switched network. IP 54 networks meet the architectural and performance requirements of 55 transporting SCSI, paving the way for the iSCSI protocol. 57 Many diskless clients sometimes bootstrap off remote SCSI devices. 58 Such diskless entities are lightweight, space-efficient and power- 59 conserving, and are increasingly popular in various environments. 61 This memo describes a standard mechanism to enable clients to 62 bootstrap themselves using the iSCSI protocol. The goal of this 63 standard is to enable iSCSI boot clients to obtain the information to 64 open an iSCSI session with the iSCSI boot server. It is possible that 65 all the information is not available at the very outset, so the memo 66 describes steps to obtain the information required to bootstrap 67 clients off an iSCSI boot server. 69 2. Requirements 71 1. There must be no restriction of network topology between the iSCSI 72 boot client and the boot server other than those in effect for 73 establishing the iSCSI session. Consequently, it is possible for an 74 iSCSI boot client to boot from an iSCSI boot server behind gateways 75 or firewalls as long as it is possible to establish an iSCSI session 76 between the client and the server. 78 2. The following represents the minimum information required for an 79 iSCSI boot client to contact an iSCSI boot server: (a) the client's 80 IP address (IPv6 or IPv4); (b) the server's iSCSI Target Name; and 81 (c) mandatory iSCSI initiator capability. 83 The above assumes that the default LUN for the boot process is 0 and 84 the default port for the iSCSI boot server is the well-known iSCSI 85 port. However, both may be overridden at the time of configuration. 87 Additional information may be required at each stage of the boot 88 process. 90 3. It is possible for the iSCSI boot client to have none of the above 91 information or capability on starting. 93 4. The client should be able to complete boot without user 94 intervention (for boots that occur during an unattended power-up). 95 However, there should be a mechanism for the user to input values so 96 as to bypass stages of the boot protocol. 98 5. Additional protocol software (for example, DHCP) may be necessary 100 Standards Track iSCSI BootStrapping Draft 27 February 2003 102 if the minimum information required for an iSCSI session is not 103 provided. 105 3. Related Work 107 The Reverse Address Resolution Protocol (RARP) [Finlayson84] through 108 the extensions defined in the Dynamic RARP (DRARP)) [Brownell96] 109 explicitly addresses the problem of network address discovery, and 110 includes an automatic IP address assignment mechanism. The Trivial 111 File Transfer Protocol (TFTP) [Sollins81] provides for transport of a 112 boot image from a boot server. BOOTP [Croft85, Reynolds93, Wimer93] 113 is a transport mechanism for a collection of configuration 114 information. BOOTP is also extensible, and official extensions have 115 been defined for several configuration parameters. DHCPv4 [Droms97, 116 Droms93] and DHCPv6 [Bound02] are standards for hosts to be 117 dynamically configured in an IP network. The Service Location 118 Protocol (SLP) provides for location of higher level services 119 [Guttman99]. 121 4. Software stage 123 Some iSCSI boot clients may lack the resources to boot up with the 124 mandatory iSCSI initiator capability. Such boot clients may choose to 125 obtain iSCSI initiator software from a boot server. Currently, there 126 are many established protocols that allow such a service to enable 127 clients to load software images. For example, BOOTP and DHCP servers 128 have the capability to provide software images on requests from boot 129 clients. 131 It is to be noted that this document does not recommend any of the 132 above protocols, and the final decision of which boot protocol is to 133 be used to load iSCSI initiator software is left to the discretion of 134 the implementor. 136 5. DHCP stage 138 In order to use an iSCSI boot server, the following pieces of 139 information are required for an ISCSI boot client. 141 - The IP address of the iSCSI boot client (IPv4 or IPv6) 143 - The IP transport endpoint for the iSCSI Target Port for the iSCSI 144 boot server. If the transport is TCP, for example, this has to 145 resolve to an IP address and a TCP port number. TCP is currently the 146 only transport approved for iSCSI. 148 - The eight-byte LUN structure identifying the Logical Unit within 150 Standards Track iSCSI BootStrapping Draft 27 February 2003 152 the iSCSI boot server. 154 At boot time, all or none of this information may be stored in the 155 iSCSI boot client. This section describes techniques for obtaining 156 the required information via the DHCP stage. Otherwise, if the iSCSI 157 boot client has all the information, the boot client may proceed 158 directly to the Boot stage. 160 An iSCSI boot client which does not know its IP address at power-on 161 may acquire its IP address via DHCP. An iSCSI boot client which is 162 capable of using both DHCPv6 and DHCPv4 should first attempt to use 163 DHCPv6 to obtain its IP address, falling back on DHCPv4 in the event 164 of failure. 166 Unless otherwise specified here, DHCP fields such as the client ID 167 and gateway information are used in an identical way as applications 168 other than iSCSI do. 170 A DHCP server (v4 or v6) MAY instruct an iSCSI client how to reach 171 its boot device. This is done using the variable length DHCP option 172 named Root Path. The use of the option field is reserved for iSCSI 173 boot use by prefacing the string with "iscsi:". 175 The option field consists of an UTF-8 [Yergeau98] string. The string 176 MUST contain only alphanumberic characters, "." , ":" and "-"; no 177 other characters are permissible. The string has the following 178 composition: 180 "iscsi:"":"":"":"":" 182 The fields "servername", "port", "protocol" and "LUN" are OPTIONAL 183 and should be left blank if there are no corresponding values. The 184 "targetname" field is not optional and MUST be provided. 186 The "servername" is the name of iSCSI server and contains either a 187 valid domain name, a literal IPv4 address, or a literal IPv6 address. 189 If the "servername" field contains a literal IPv4 address, the IPv4 190 address MUST be in standard dotted decimal notation as defined in 191 Section 2.1 of RFC 1123 [Braden89]. 193 If the "servername" field contains an IPv6 address, the address MUST 194 be represented in the IPv6 address format x.x.x.x.x.x.x.x where the 195 'x's are the hexadecimal values of the eight 16-bit pieces of the 196 address. Note that this format representation is specific to iSCSI 197 boot. 199 If the "servername" is a domain name, the name MUST be a fully 201 Standards Track iSCSI BootStrapping Draft 27 February 2003 203 qualified domain name (FQDN) and should abide by the rules specified 204 in Sections 3.1 and 3.5 of RFC 1034 [Mockaopetris87] and the reply 205 from the host configuration server should contain the Domain Name 206 Server Option [Alexander93]. It must also be pointed out that the 207 use of DNS for address translation in enterprise environments must 208 contain adequate levels of fault tolerance and security. 210 If the "servername" field contains 4 decimal components, the 211 "servername" is assumed to be an IPv4 address. If there are more than 212 4 decimal components or if there is a hexadecimal component, the the 213 "servername" is assumed to be an IPv6 address. If the least 214 significant (rightmost) component is an approved domain extension, 215 then the "servername" field is assumed to be a domain name. If the 216 "servername" field is left blank, then no default value is assumed in 217 its place. 219 The "protocol" field is the decimal representation of the IANA- 220 approved string for the trasport protocol to be used for iSCSI. If 221 the protocol field is left bank, the default value is assumed to be 222 "6" for TCP. The transport protocol MUST have been approved for use 223 in iSCSI; currently, the only approved protocol is TCP. 225 The "port" is the decimal representation of the port on which the 226 iSCSI boot server is listening. If not specified, the port defaults 227 to the well-known iSCSI port. 229 The "LUN" field is a hexadecimal representation of the LU number. If 230 the LUN field is blank, then LUN 0 is assumed. If the LUN field is 231 not blank, the representation MUST be divided into four groups of 232 four hexadecimal digits, separated by "-". Digits above 9 may be 233 either lower or upper case. An example of such a representation 234 would be 4752-3A4F-6b7e-2F99. For the sake of brevity, at most three 235 leading zero ("0") digits MAY be omitted in any group of hexadecimal 236 digits. Thus, the "LUN" representation 6734-9-156f-127 is equivalent 237 to 6734-0009-156f-0127. Furthermore, trailing groups containing only 238 the "0" digit MAY be omitted along with the preceding "-". So, the 239 "LUN" representation 4186-9 is equivalent to 4186-0009-0000-0000. 240 Other concise representations of the LUN field MUST NOT be used. 242 Note that SCSI targets are allowed to present different LU numberings 243 for different SCSI initiators, so that to our knowledge nothing 244 precludes a SCSI target from exporting several different LUs to 245 several different SCSI initiators as their respective LUN 0s. 247 The "targetname" field is an iSCSI Name that is defined by the iSCSI 248 standard [Satran02] to uniquely identify an iSCSI target. 250 If the "servername" field is provided by DHCP, then that field is 252 Standards Track iSCSI BootStrapping Draft 27 February 2003 254 used in conjunction with other associated fields to contact the boot 255 server in the Boot stage (Section 7). However, if the "servername" 256 field is not provided, then the "targetname" field is then used in 257 the Discovery Service stage in conjunction with other associated 258 fields. (Section 6). 260 6. Discovery Service stage 262 This stage is required if the DHCP server (v4 or v6) is unaware of 263 any iSCSI boot servers or if the DHCP server is unable to provide the 264 minimum information required to connect to the iSCSI boot server 265 other than the targetname. 267 The discovery service is based on the SLP protocol [Guttman99, 268 Bakke02] and is an instantiation of the SLP Service or Directory 269 Agent. 271 The iSCSI boot client may have obtained the targetname of the iSCSI 272 boot server in the DHCP stage (Section 5). In that case, the iSCSI 273 boot client queries the Discovery Service using query string 1 of the 274 iSCSI Target Concrete Service Type Template as specified in Section 275 6.2 of the iSCSI SLP interaction document [Bakke02] to resolve the 276 targetname to an IP address and port number. Once this is obtained, 277 the iSCSI boot client proceeds to the Boot stage (Section 7). 279 It is possible that the port number obtained from the Discovery 280 Service may conflict with the one obtained from the DHCP service. In 281 such a case, the implementor has the option to try both port numbers 282 in the Boot stage. 284 If the iSCSI boot client does not have any targetname information, 285 the iSCSI boot client then may query the Discovery Service with query 286 string 4 of the iSCSI Target Concrete Service Type Template as 287 specified in Section 6.2 of the iSCSI SLP interaction document 288 [Bakke02]. In response to this query, the discovery service provides 289 the boot client with a list of iSCSI boot servers the boot client is 290 allowed to access. 292 If the list of iSCSI boot servers is empty, subsequent actions are 293 left to the discretion of the implementor. Otherwise, the iSCSI boot 294 client may contact any iSCSI boot server in the list. Moreover, the 295 order in which iSCSI boot servers are contacted is also left to the 296 discretion of the implementor. 298 7. Boot stage 300 Once the iSCSI boot client has obtained the minimum information to 302 Standards Track iSCSI BootStrapping Draft 27 February 2003 304 open an iSCSI session with the iSCSI boot server, the actual booting 305 process can start. 307 The actual sequence of iSCSI commands needed to complete the boot 308 process is left to the implementor. This was done because of varying 309 requirements from different vendors and equipment, making it 310 difficult to specify a common subset of the iSCSI standard that would 311 be acceptable to everybody. 313 The iSCSI session established for boot may be taken over by the 314 booted software in the iSCSI boot client. 316 8. Security Considerations 318 The security discussion is centered around securing the communication 319 involved in the iSCSI boot process. 321 However, the issue of applying credentials to a boot image loaded 322 through the iSCSI boot mechanism is outside the scope of this 323 document. One key difference between the iSCSI boot mechanism and 324 BOOTP-based image loading is the fact that the identity of a boot 325 image may not be known when the Boot stage starts. The identity of 326 certain boot images and their locations are known only after 327 examining the contents of a boot disk exposed by the iSCSI boot 328 service. Furthermore, images themselves may recursively load other 329 images based on both hardware configurations and user input. 330 Consequently, a practical way to verify loaded boot images is to make 331 sure that each image loading software verify the image to be loaded 332 using a mechanism of their choice. 334 The considerations involved in designing a security architecture for 335 the iSCSI boot process include configuration, deployment and 336 provisioning issues apart from typical security considerations. 338 The software stage SHOULD not be involved in a secure iSCSI boot 339 process as this would add the additional complexity of trying to 340 secure the process of loading the software necessary to run the later 341 stages of iSCSI boot. It is therefore assumed that all the necessary 342 software is resident on the iSCSI boot client. 344 In the case where the DHCP stage is necessary, the iSCSI boot client 345 must contact the DHCP server using IPSEC. Since DHCP server software 346 is freely available and can be deployed easily, care must be taken to 347 make sure that the communication is secure. Consequently, pre-shared 348 keys MUST be avoided in authenticating the IPSEC communication 349 channel. As public key techniques are not recommended for 350 authenticating the IPSEC communication channel in the Boot stage, an 352 Standards Track iSCSI BootStrapping Draft 27 February 2003 354 implementation SHOULD avoid these techniques to avoid two different 355 authentication mechanisms. 357 In the context of the secure iSCSI boot process, the reply from the 358 DHCP server in the DHCP stage MUST include the servername in IPv4 (or 359 IPv6) format to avoid reliance on a DNS server (for resolving names) 360 or a SLP server (to look up targetnames). This reduces the number of 361 entities involved in the secure iSCSI boot process. 363 The final communication between the iSCSI boot client and the boot 364 server in the Boot stage is secured with the help of IPSEC. The 365 communication must adhere to the recommendations in the main iSCSI 366 draft [Satran02] for the choice of certification, authentication and 367 encryption algorithms. However, since the iSCSI boot client is 368 likely to have a dynamic IP address, pre-shared keys MUST be avoided 369 in authenticating the IPSEC communication channel. 371 The mechanism for securing the iSCSI boot process SHOULD not be 372 enabled by default so as to avoid the configuration, deployment and 373 provisioning requirements of the secure boot process. 375 Another point to be noted is that if a boot image inherits an iSCSI 376 session from a previously loaded boot image, the boot image also 377 inherts the security properties of the iSCSI session. 379 Acknowledgments 381 We wish to thank John Hufferd for taking the initiative to form the 382 iSCSI boot team. We also wish to thank Doug Otis, Julian Satran, 383 Bernard Aboba, David Robinson, Mark Bakke and Mallikarjun Chadalapaka 384 for helpful suggestions and pointers regarding the draft document. 386 Normative References 388 [Alexander93] Alexander, S., and R. Droms, "DHCP Options and BOOTP 389 Vendor 390 Extensions", RFC 2132, Lachman Technology, Inc., Bucknell 391 University, October 1993. 393 [Bakke02] Bakke, M., et al. "Finding iSCSI Targets and Name Servers 394 using SLP", Work in Progress, March 2002. 396 [Bound02] Bound, J., Canney, M., and Perkins, C., "Dynamic Host 397 Configuration 398 Protocol for IPv6", Work in Progress, June 2002. 400 [Braden89] Braden, R., "Requirements for Internet Hosts - Application 401 and Support", RFC 1123, October 1989. 403 Standards Track iSCSI BootStrapping Draft 27 February 2003 405 [Bradner96] Bradner, S., "The Internet Standards Process -- 406 Revision 3", RFC 2026, October 1996. 408 [Bradner97] Bradner, S. "Key Words for use in RFCs to indicate 409 Requirement Levels", RFC 2119, Harvard University, March 1997. 411 [Croft85] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", 412 RFC 951, 413 Stanford and SUN Microsystems, September 1985. 415 [Droms93] Droms, D., "Interoperation between DHCP and BOOTP" RFC 416 1534, 417 Bucknell University, October 1993. 419 [Droms97] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 420 Bucknell University, March 1997. 422 [Droms01] Droms, R., Arbaugh, W., "Authentication for DHCP Messages", 423 RFC 3118, June 2001. 425 [Guttman99] Guttman, E., Perkins, C., Verizades, J., Day, M., 426 "Service Location Protocol v2", RFC 2608, June 1999. 428 [Mockaopetris87] Mockaopertis, P., "Domain Names - Concepts and 429 Facilities", RFC 1034, November 1987. 431 [Reynolds93] Reynolds, J., "BOOTP Vendor Information Extensions", RFC 432 1497, 433 USC/Information Sciences Institute, August 1993. 435 [Satran02] Satran, J. et al., "iSCSI", Work in Progress, September 436 2002. 438 [Yergeau98] Yergeau, F., "UTF-8: A Transformation Format for 439 ISO-10646", RFC 2279, January 1998. 441 [Wimer93] Wimer, W., "Clarifications and Extensions for the Bootstrap 442 Protocol", RFC 1532, Carnegie Mellon University, October 1993. 444 Informative References 446 [Brownell96] Brownell, D, "Dynamic RARP extensions for Automatic 447 Network Adress 448 Acquisition", RFC 1931, SUN Microsystems, April 1996. 450 [Finlayson84] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A 451 Reverse 452 Address Resolution Protocol", RFC 903, Stanford, June 1984. 454 Standards Track iSCSI BootStrapping Draft 27 February 2003 456 [Sollins81] Sollins, K., "The TFTP Protocol (Revision 2)", RFC 783, 457 NIC, 458 June 1981. 460 Authors' Addresses 462 Prasenjit Sarkar 463 IBM Almaden Research Center 464 650 Harry Road 465 San Jose, CA 95120, USA 466 Phone: +1 408 927 1417 467 Email: psarkar@almaden.ibm.com 469 Duncan Missimer 470 Rhapsody Networks 471 3450 W Warren Avenue, 472 Fremont, CA 94538, USA 473 Phone: +1 510 743 3095 474 Email: dmissimer@rhapsodynetworks.com 476 Constantine Sapuntzakis 477 Stanford University 478 353 Serra Hall #406 479 Stanford, CA 94306, USA 480 Phone: +1 650 520 0205 481 Email: csapuntz@stanford.edu 483 Full Copyright Statement 485 "Copyright (C) The Internet Society (date). All Rights Reserved. This 486 document and translations of it may be copied and furnished to 487 others, and derivative works that comment on or otherwise explain it 488 or assist in its implementation may be prepared, copied, published 489 and distributed, in whole or in part, without restriction of any 490 kind, provided that the above copyright notice and this paragraph are 491 included on all such copies and derivative works. However, this 492 document itself may not be modified in any way, such as by removing 493 the copyright notice or references to the Internet Society or other 494 Internet organizations, except as needed for the purpose of 495 developing Internet standards in which case the procedures for 496 copyrights defined in the Internet Standards process must be 497 followed, or as required to translate it into languages other than 498 English. 500 The limited permissions granted above are perpetual and will not be 501 revoked by the Internet Society or its successors or assigns. 503 Standards Track iSCSI BootStrapping Draft 27 February 2003 505 This document and the information contained herein is provided on an 506 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 507 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 508 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 509 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 510 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 512 Intellectual Property Rights 514 The IETF takes no position regarding the validity or scope of 515 any intellectual property or other rights that might be claimed 516 to pertain to the implementation or use of the technology 517 described in this document or the extent to which any license 518 under such rights might or might not be available; neither does 519 it represent that it has made any effort to identify any such 520 rights. Information on the IETF's procedures with respect to 521 rights in standards-track and standards-related documentation 522 can be found in BCP-11. Copies of claims of rights made 523 available for publication and any assurances of licenses to 524 be made available, or the result of an attempt made 525 to obtain a general license or permission for the use of such 526 proprietary rights by implementors or users of this 527 specification can be obtained from the IETF Secretariat." 529 The IETF invites any interested party to bring to its 530 attention any copyrights, patents or patent applications, or 531 other proprietary rights which may cover technology that may be 532 required to practice this standard. Please address the 533 information to the IETF Executive Director.