idnits 2.17.1 draft-hollenbeck-rfc2832bis-01.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 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 (June 7, 2002) is 7992 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) ** Obsolete normative reference: RFC 2373 (ref. '2') (Obsoleted by RFC 3513) ** Downref: Normative reference to an Informational RFC: RFC 2832 (ref. '3') == Outdated reference: A later version (-09) exists of draft-ietf-provreg-epp-06 == Outdated reference: A later version (-07) exists of draft-ietf-provreg-epp-domain-04 == Outdated reference: A later version (-07) exists of draft-ietf-provreg-epp-host-04 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft S. Veeramachaneni 4 Expires: December 6, 2002 S. Yalamanchilli 5 VeriSign, Inc. 6 June 7, 2002 8 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 9 draft-hollenbeck-rfc2832bis-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 6, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document updates version 1.1.0 of the NSI Registry Registrar 41 Protocol specified in RFC 2832. The changes described in this 42 document combined with the base specification documented in RFC 2832 43 specify version 2.0.0 of the VeriSign Registry Registrar Protocol. 45 Conventions Used In This Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [1]. 51 In examples, "C:" represents lines sent by a protocol client and "S:" 52 represents lines returned by a protocol server. 54 Discussion Venue 56 The authors welcome discussion and comments relating to the topics 57 presented in this document. Though direct comments to the authors 58 are welcome, public discussion is taking place on the "rrp@verisign- 59 grs.com" mailing list. To join the list, send a message to 60 "majordomo@verisign-grs.com" with the words "subscribe rrp" in the 61 body of the message. List archives [7] are available on the World 62 Wide Web. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . 3 68 2.1 Entity Status Codes . . . . . . . . . . . . . . . . . . . . 3 69 2.1.1 Domain Status Codes . . . . . . . . . . . . . . . . . . . . 3 70 2.1.2 Name Server Status Codes . . . . . . . . . . . . . . . . . . 5 71 2.1.3 Status Code ABNF . . . . . . . . . . . . . . . . . . . . . . 6 72 2.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6 73 2.2.1 New Response Codes . . . . . . . . . . . . . . . . . . . . . 6 74 2.2.2 Modified Response Codes . . . . . . . . . . . . . . . . . . 7 75 2.3 TRANSFER Command Update . . . . . . . . . . . . . . . . . . 8 76 2.4 IPv6 Name Server Addresses . . . . . . . . . . . . . . . . . 9 77 3. Internationalization Considerations . . . . . . . . . . . . 10 78 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 79 5. Security Considerations . . . . . . . . . . . . . . . . . . 11 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 81 Normative References . . . . . . . . . . . . . . . . . . . . 11 82 Informative References . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 84 A. Appendix A: Change History . . . . . . . . . . . . . . . . . 12 85 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 87 1. Introduction 89 The Network Solutions, Inc. (NSI) Registry Registrar Protocol (RRP) 90 was developed by NSI in 1998 and 1999 to allow multiple registrars to 91 provide second level Internet domain name registration services in 92 the top level domains (TLDs) administered by the NSI TLD registry. 93 Version 1.1.0 of the NSI RRP was published as Informational RFC 2832 94 [3] in May 2000. This document describes changes to RFC 2832 that 95 specify version 2.0.0 of the protocol. 97 2. Protocol Updates 99 This specification describes several modifications to RFC 2832 [3]: 100 entity status codes have been completely redesigned, two new response 101 codes have been added and the descriptions of three others have been 102 changed, domain TRANSFER command processing is updated to allow a 103 client to cancel a requested domain transfer, and support for IPv6 104 name server addresses is added. 106 2.1 Entity Status Codes 108 Section 6 of RFC 2832 [3] is replaced with the new text included 109 here. The new entity status codes described in this document map 110 directly to object status codes defined by Extensible Provisioning 111 Protocol (EPP, [4]) domain [5] and host [6] object mappings, allowing 112 clients to access the same data store via either protocol with a 113 consistent view of an entity's current status. 115 The status of an entity can be viewed using the RRP STATUS command 116 and modified using the RRP MOD command. Both the registry and the 117 sponsoring registrar MAY view and change the status of an entity. 118 The criteria for status changes are highly dependent on registry and 119 registrar business models and are thus beyond the scope of this 120 specification. 122 An entity can have more than one assigned status, e.g., CLIENTHOLD 123 and CLIENTUPDATEPROHIBITED. If an entity is in OK status, then the 124 entity can only be in this status. When a registrar sets an entity 125 to CLIENTHOLD, the registry MUST automatically remove the OK status. 126 When the registrar removes the CLIENTHOLD and other entity statuses, 127 the registry MUST automatically set the entity status to OK. 129 2.1.1 Domain Status Codes 131 OK: This is the default status of a domain name. The registry sets 132 the domain to this status. The domain name can be updated, renewed, 133 deleted, or transferred. The domain SHALL be included in the zone 134 when in this status if the domain has at least one delegated name 135 server. 137 SERVERHOLD: The registry sets the domain to this status. The domain 138 name can be updated, renewed, deleted, or transferred. The domain 139 name SHALL NOT be included in the zone when in this status. 141 SERVERDELETEPROHIBITED: The registry sets the domain to this status. 142 Requests to delete the domain name MUST be rejected. The domain name 143 can be modified, renewed, or transferred. The domain SHALL be 144 included in the zone when in this status if the domain has at least 145 one delegated name server. 147 SERVERTRANSFERPROHIBITED: The registry sets the domain to this 148 status. Requests to transfer the domain name MUST be rejected. The 149 domain name can be modified, renewed, or deleted. The domain SHALL 150 be included in the zone when in this status if the domain has at 151 least one delegated name server. 153 SERVERUPDATEPROHIBITED: The registry sets the domain to this status. 154 Requests to update the domain name (except to remove this status) 155 MUST be rejected. The domain name can be transferred, renewed, or 156 deleted. The domain SHALL be included in the zone when in this 157 status if the domain has at least one delegated name server. 159 SERVERRENEWPROHIBITED: The registry sets the domain to this status. 160 Requests to renew the domain name MUST be rejected. The domain name 161 can be transferred, deleted, or updated. The domain SHALL be 162 included in the zone when in this status if the domain has at least 163 one delegated name server. 165 CLIENTHOLD: The registrar sets the domain to this status. The domain 166 name can be updated, renewed, deleted, or transferred. The domain 167 name SHALL NOT be included in the zone when in this status. 169 CLIENTDELETEPROHIBITED: The registrar sets the domain to this status. 170 Requests to delete the domain name MUST be rejected. The domain name 171 can be modified, renewed, or transferred. The domain SHALL be 172 included in the zone when in this status if the domain has at least 173 one delegated name server. 175 CLIENTTRANSFERPROHIBITED: The registrar sets the domain to this 176 status. Requests to transfer the domain name MUST be rejected. The 177 domain name can be modified, renewed, or deleted. The domain SHALL 178 be included in the zone when in this status if the domain has at 179 least one delegated name server. 181 CLIENTUPDATEPROHIBITED: The registrar sets the domain to this status. 182 Requests to update the domain name (except to remove this status) 183 MUST be rejected. The domain name can be transferred, renewed, or 184 deleted. The domain SHALL be included in the zone when in this 185 status if the domain has at least one delegated name server. 187 CLIENTRENEWPROHIBITED: The registrar sets the domain to this status. 188 Requests to renew the domain name MUST be rejected. The domain name 189 can be transferred, deleted, or updated. The domain SHALL be 190 included in the zone when in this status if the domain has at least 191 one delegated name server. 193 PENDINGDELETE: The registry sets the domain to this status when the 194 registrar successfully completes a DEL command and the domain has not 195 yet been purged from the registry database. Once in this status all 196 registrar requests to act on the domain name MUST be rejected. The 197 registry MAY remove this status and abort the pending purge 198 operation. 200 PENDINGTRANSFER: The registry sets the domain to this status when a 201 request for a transfer is accepted. The domain name cannot be 202 renewed, deleted, or updated when in this status. 204 2.1.2 Name Server Status Codes 206 OK: This is the default status of a name server. The registry sets 207 the name server to this status. The name server can be updated or 208 deleted. 210 SERVERDELETEPROHIBITED: The registry sets the name server to this 211 status. Requests to delete the name server MUST be rejected. The 212 name server can be modified or renewed. 214 SERVERUPDATEPROHIBITED: The registry sets the name server to this 215 status. Requests to update the name server (except to remove this 216 status) MUST be rejected. The name server can be renewed or deleted. 218 CLIENTDELETEPROHIBITED: The registrar sets the name server to this 219 status. Requests to delete the name server MUST be rejected. The 220 name server can be modified or renewed. 222 CLIENTUPDATEPROHIBITED: The registrar sets the name server to this 223 status. Requests to update the name server (except to remove this 224 status) MUST be rejected. The name server can be renewed or deleted. 226 PENDINGDELETE: The registry sets the domain to this status when the 227 registrar successfully completes a DEL command for the parent domain 228 of the name server and the domain has not yet been purged from the 229 registry database. Once in this status all registrar requests to act 230 on the name server MUST be rejected; delegations to this name server 231 MUST also be rejected. The registry MAY remove this status and abort 232 the pending purge operation. 234 PENDINGTRANSFER: The registry sets the name server to this status 235 when a request for a transfer of the name server's parent domain is 236 accepted. The name server MAY be deleted or updated when in this 237 status. 239 LINKED: The registry sets the name server to this status when one or 240 more domains have been delegated to the name server. The name server 241 MUST NOT be deleted when in this status. The name server MAY be 242 updated when in this status. 244 2.1.3 Status Code ABNF 246 Section 7 of RFC 2832 [3] is updated to include the status code 247 changes described in Section 2.1.1 and Section 2.1.2: 249 domainstatus = "OK" / "CLIENTHOLD" / "CLIENTUPDATEPROHIBITED" / 250 "CLIENTDELETEPROHIBITED" / "CLIENTRENEWPROHIBITED" / 251 "CLIENTTRANSFERPROHIBITED" / "SERVERHOLD" / 252 "SERVERUPDATEPROHIBITED" / "SERVERDELETEPROHIBITED" / 253 "SERVERRENEWPROHIBITED" / "SERVERTRANSFERPROHIBITED" / 254 "PENDINGDELETE" / "PENDINGTRANSFER" 255 nameserverstatus = "OK" / "CLIENTUPDATEPROHIBITED" / 256 "CLIENTDELETEPROHIBITED" / "SERVERUPDATEPROHIBITED" / 257 "SERVERDELETEPROHIBITED" / "LINKED" / 258 "PENDINGTRANSFER" / "PENDINGDELETE" 260 2.2 Response Codes 262 Section 5.1 of RFC 2832 [3] is updated to include two additional 263 error response codes and to modify three existing response codes. 265 2.2.1 New Response Codes 267 510 Invalid encoding 269 The value of a domain name or name server entity contains an invalid 270 ASCII compatible encoding used to represent an internationalized 271 domain or host name. The encoding is checked and verified in two 272 situations: when registering an internationalized domain name or name 273 server name, and when changing the name of a name server and the new 274 name of the server is internationalized. 276 Section 5.2 of RFC 2832 [3] is updated to include the addition of 277 response code 510 to the possible error values returned from the ADD 278 command: 280 Command: ADD 281 Success: 200, 220 282 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 283 535, 540, 541, 545, 546, 547, 549, 550, 554 285 557 Name server status does not allow for operation 287 The status of the name server does not allow the requested operation. 288 This occurs when a registrar tries to modify a name server that is 289 flagged as CLIENTUPDATEPROHIBITED or SERVERUPDATEPROHIBITED or tries 290 to delete a name server that is flagged as CLIENTDELETEPROHIBITED or 291 SERVERDELETEPROHIBITED. 293 Section 5.2 of RFC 2832 [3] is updated to include the addition of 294 response code 557 to the possible error values returned from the DEL 295 command: 297 Command: DEL 298 Success: 200, 220 299 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 300 533, 541, 544, 545, 547, 549, 551, 552, 553, 557 302 Section 5.2 of RFC 2832 [3] is updated to include the addition of 303 response codes 510 and 557 to the possible error values returned from 304 the MOD command: 306 Command: MOD 307 Success: 200, 220 308 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 309 535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553, 557 311 2.2.2 Modified Response Codes 313 551 Parent domain status does not allow for operation 315 The status of the parent domain does not allow the requested 316 operation. This occurs when a registrar tries to modify a name 317 server whose parent domain is flagged as CLIENTUPDATEPROHIBITED or 318 SERVERUPDATEPROHIBITED or the registrar tries to delete a name server 319 whose parent domain is flagged as CLIENTDELETEPROHIBITED or 320 SERVERDELETEPROHIBITED. 322 552 Domain status does not allow for operation 324 The status of the domain does not allow the requested operation. 326 This occurs when a registrar tries to modify a domain that is flagged 327 as CLIENTUPDATEPROHIBITED or SERVERUPDATEPROHIBITED or tries to 328 delete a domain that is flagged as CLIENTDELETEPROHIBITED or 329 SERVERDELETEPROHIBITED or tries to renew a domain that is flagged as 330 CLIENTRENEWPROHIBITED or SERVERRENEWPROHIBITED or tries to transfer a 331 domain that is flagged as CLIENTTRANSFERPROHIBITED or 332 SERVERTRANSFERPROHIBITED. 334 553 Operation not allowed. Domain pending transfer 336 The status of the domain does not allow the requested operation. The 337 registrar is attempting to delete a domain that is pending approval 338 or denial of a transfer request. The domain is flagged as 339 PENDINGTRANSFER in the registry. 341 2.3 TRANSFER Command Update 343 Section 4.3.10 of RFC 2832 [3] is updated to include an additional 344 TRANSFER command processing option. 346 Old text: 348 Authorized User: All registrars MAY use the TRANSFER command to 349 request transfer of registration service authority to the requesting 350 registrar. Only the current sponsoring registrar of a domain name 351 may explicitly approve or reject a requested transfer. The registry 352 MAY implicitly approve or reject requested transfers after a fixed 353 amount of time. 355 New text: 357 Authorized User: All registrars MAY use the TRANSFER command to 358 request transfer of registration service authority to the requesting 359 registrar. Only the current sponsoring registrar of a domain name 360 may explicitly approve a requested transfer. The current sponsoring 361 registrar MAY explicitly reject a requested transfer. The registry 362 MAY implicitly approve or reject requested transfers after a fixed 363 amount of time. The requesting registrar MAY cancel a pending 364 request, but the request to cancel the transfer MUST be sent before 365 it has been explicitly approved or rejected by the current sponsoring 366 registrar or it has been implicitly approved or rejected by the 367 registry. 369 Example: 371 A registrar cancels a previously requested domain transfer: 373 C:transfer 374 C:-Approve:No 375 C:EntityName:Domain 376 C:DomainName:example.com 377 C:. 378 S:200 Command completed successfully 379 S:. 381 2.4 IPv6 Name Server Addresses 383 Section 7 of RFC 2832 [3] is updated to include support for name 384 servers using IPv6 addresses. IPv6 addressing architecture is 385 described in RFC 2373 [2]. This ABNF grammar supplements the grammar 386 defined in RFC 2832. 388 ; Lexical Tokens 390 hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f 392 doubleoctet = 1*4hexdigit 394 docolon = doubleoctet colon 396 colondo = colon doubleoctet 398 ip-address = ip-address-v4 / ip-address-v6 400 ; ipv4 addresses 401 ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit 403 ip-address-v6 = ip-address-v6-standard / ip-address-v6-compressed 404 ; Standard form of IPv6 addresses 405 ; 8 hexdigit strings of length 1-4 separated by colons 406 ; 407 ; Eg: 10AA:0:0:00:8:800:200C:417A 409 ip-address-v6-standard = doubleoctet 7colondo 411 ; Compressed form of IPv6 addresses 412 ; Runs of zero-value octets are represented by '::' 413 ; 414 ; Examples: 415 ; :: ==> 0:0:0:0:0:0:0:0 416 ; 417 ; 1:: ==> 1:0:0:0:0:0:0:0 418 ; 2:2:: ==> 2:2:0:0:0:0:0:0 419 ; 7:7:7:7:7:7:7:: ==> 7:7:7:7:7:7:7:0 420 ; 421 ; ::1 ==> 0:0:0:0:0:0:0:1 422 ; ::2:2 ==> 0:0:0:0:0:0:2:2 423 ; ::7:7:7:7:7:7:7 ==> 0:7:7:7:7:7:7:7 424 ; 425 ; E::1 ==> E:0:0:0:0:0:0:1 426 ; E::2:2 ==> E:0:0:0:0:0:2:2 427 ; E::6:6:6:6:6:6 ==> E:0:6:6:6:6:6:6 428 ; 429 ; E:E::1 ==> E:E:0:0:0:0:0:1 430 ; E:E::2:2 ==> E:E:0:0:0:0:2:2 431 ; E:E::5:5:5:5:5 ==> E:E:0:5:5:5:5:5 432 ; 433 ; E:E:E::1 ==> E:E:E:0:0:0:0:1 434 ; E:E:E::2:2 ==> E:E:E:0:0:0:2:2 435 ; E:E:E::4:4:4:4 ==> E:E:E:0:4:4:4:4 436 ; 437 ; E:E:E:E::1 ==> E:E:E:E:0:0:0:1 438 ; E:E:E:E::2:2 ==> E:E:E:E:0:0:2:2 439 ; E:E:E:E::3:3:3 ==> E:E:E:E:0:3:3:3 440 ; 441 ; E:E:E:E:E::1 ==> E:E:E:E:E:0:0:1 442 ; E:E:E:E:E::2:2 ==> E:E:E:E:E:0:2:2 443 ; 444 ; E:E:E:E:E:E::1 ==> E:E:E:E:E:E:0:1 446 ip-address-v6-compressed = colon colon 447 ip-address-v6-compressed =/ 1*7docolon colon 448 ip-address-v6-compressed =/ colon 1*7colondo 449 ip-address-v6-compressed =/ docolon 1*6colondo 450 ip-address-v6-compressed =/ 2docolon 1*5colondo 451 ip-address-v6-compressed =/ 3docolon 1*4colondo 452 ip-address-v6-compressed =/ 4docolon 1*3colondo 453 ip-address-v6-compressed =/ 5docolon 1*2colondo 454 ip-address-v6-compressed =/ 6docolon colondo 456 3. Internationalization Considerations 458 This document does not introduce any new internationalization 459 considerations that are not already documented in RFC 2832 [3]. 461 4. IANA Considerations 463 This document does not introduce any new IANA considerations that are 464 not already documented in RFC 2832 [3]. 466 5. Security Considerations 468 This document does not introduce any new security considerations that 469 are not already documented in RFC 2832 [3]. 471 6. Acknowledgements 473 The authors graciously acknowledge the contributions of John Brady, 474 Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt. 476 Normative References 478 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 479 Levels", BCP 14, RFC 2119, March 1997. 481 [2] Hinden, R. and S. Deering, "IP Version 6 Addressing 482 Architecture", RFC 2373, July 1998. 484 [3] Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar 485 Protocol (RRP) Version 1.1.0", RFC 2832, May 2000. 487 Informative References 489 [4] Hollenbeck, S., "Extensible Provisioning Protocol", draft-ietf- 490 provreg-epp-06 (work in progress), January 2002. 492 [5] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name 493 Mapping", draft-ietf-provreg-epp-domain-04 (work in progress), 494 January 2002. 496 [6] Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping", 497 draft-ietf-provreg-epp-host-04 (work in progress), January 2002. 499 URIs 501 [7] 503 Authors' Addresses 505 Scott Hollenbeck 506 VeriSign, Inc. 507 21345 Ridgetop Circle 508 Dulles, VA 20166-6503 509 US 511 EMail: shollenbeck@verisign.com 513 Srikanth Veeramachaneni 514 VeriSign, Inc. 515 21345 Ridgetop Circle 516 Dulles, VA 20166-6503 517 US 519 EMail: sveerama@verisign.com 521 Suresh Yalamanchilli 522 VeriSign, Inc. 523 21345 Ridgetop Circle 524 Dulles, VA 20166-6503 525 US 527 EMail: syalamanchilli@verisign.com 529 Appendix A. Appendix A: Change History 531 (Note to RFC editor: please remove this section completely before 532 publication as an RFC.) 534 The following changes were made to produce version -01 from -00: 536 o Editorial fixes throughout. 538 o Added Section 2.1. 540 o Updated Section 2.2. 542 o Fixed typos in IPv6 address examples given in Section 2.4. 544 Full Copyright Statement 546 Copyright (C) The Internet Society (2002). All Rights Reserved. 548 This document and translations of it may be copied and furnished to 549 others, and derivative works that comment on or otherwise explain it 550 or assist in its implementation may be prepared, copied, published 551 and distributed, in whole or in part, without restriction of any 552 kind, provided that the above copyright notice and this paragraph are 553 included on all such copies and derivative works. However, this 554 document itself may not be modified in any way, such as by removing 555 the copyright notice or references to the Internet Society or other 556 Internet organizations, except as needed for the purpose of 557 developing Internet standards in which case the procedures for 558 copyrights defined in the Internet Standards process must be 559 followed, or as required to translate it into languages other than 560 English. 562 The limited permissions granted above are perpetual and will not be 563 revoked by the Internet Society or its successors or assigns. 565 This document and the information contained herein is provided on an 566 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 567 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 568 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 569 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 570 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 572 Acknowledgement 574 Funding for the RFC Editor function is currently provided by the 575 Internet Society.