Network Working Group S. Hollenbeck Internet-Draft S. Veeramachaneni Expires: December 6, 2002 S. Yalamanchilli VeriSign, Inc. June 7, 2002 VeriSign Registry Registrar Protocol (RRP) Version 2.0.0 draft-hollenbeck-rfc2832bis-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 6, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document updates version 1.1.0 of the NSI Registry Registrar Protocol specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Hollenbeck, et al. Expires December 6, 2002 [Page 1] Internet-Draft VeriSign RRP v2.0.0 June 2002 In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server. Discussion Venue The authors welcome discussion and comments relating to the topics presented in this document. Though direct comments to the authors are welcome, public discussion is taking place on the "rrp@verisign- grs.com" mailing list. To join the list, send a message to "majordomo@verisign-grs.com" with the words "subscribe rrp" in the body of the message. List archives [7] are available on the World Wide Web. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Entity Status Codes . . . . . . . . . . . . . . . . . . . . 3 2.1.1 Domain Status Codes . . . . . . . . . . . . . . . . . . . . 3 2.1.2 Name Server Status Codes . . . . . . . . . . . . . . . . . . 5 2.1.3 Status Code ABNF . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Response Codes . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 New Response Codes . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 Modified Response Codes . . . . . . . . . . . . . . . . . . 7 2.3 TRANSFER Command Update . . . . . . . . . . . . . . . . . . 8 2.4 IPv6 Name Server Addresses . . . . . . . . . . . . . . . . . 9 3. Internationalization Considerations . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 Normative References . . . . . . . . . . . . . . . . . . . . 11 Informative References . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12 A. Appendix A: Change History . . . . . . . . . . . . . . . . . 12 Full Copyright Statement . . . . . . . . . . . . . . . . . . 13 Hollenbeck, et al. Expires December 6, 2002 [Page 2] Internet-Draft VeriSign RRP v2.0.0 June 2002 1. Introduction The Network Solutions, Inc. (NSI) Registry Registrar Protocol (RRP) was developed by NSI in 1998 and 1999 to allow multiple registrars to provide second level Internet domain name registration services in the top level domains (TLDs) administered by the NSI TLD registry. Version 1.1.0 of the NSI RRP was published as Informational RFC 2832 [3] in May 2000. This document describes changes to RFC 2832 that specify version 2.0.0 of the protocol. 2. Protocol Updates This specification describes several modifications to RFC 2832 [3]: entity status codes have been completely redesigned, two new response codes have been added and the descriptions of three others have been changed, domain TRANSFER command processing is updated to allow a client to cancel a requested domain transfer, and support for IPv6 name server addresses is added. 2.1 Entity Status Codes Section 6 of RFC 2832 [3] is replaced with the new text included here. The new entity status codes described in this document map directly to object status codes defined by Extensible Provisioning Protocol (EPP, [4]) domain [5] and host [6] object mappings, allowing clients to access the same data store via either protocol with a consistent view of an entity's current status. The status of an entity can be viewed using the RRP STATUS command and modified using the RRP MOD command. Both the registry and the sponsoring registrar MAY view and change the status of an entity. The criteria for status changes are highly dependent on registry and registrar business models and are thus beyond the scope of this specification. An entity can have more than one assigned status, e.g., CLIENTHOLD and CLIENTUPDATEPROHIBITED. If an entity is in OK status, then the entity can only be in this status. When a registrar sets an entity to CLIENTHOLD, the registry MUST automatically remove the OK status. When the registrar removes the CLIENTHOLD and other entity statuses, the registry MUST automatically set the entity status to OK. 2.1.1 Domain Status Codes OK: This is the default status of a domain name. The registry sets the domain to this status. The domain name can be updated, renewed, deleted, or transferred. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name Hollenbeck, et al. Expires December 6, 2002 [Page 3] Internet-Draft VeriSign RRP v2.0.0 June 2002 server. SERVERHOLD: The registry sets the domain to this status. The domain name can be updated, renewed, deleted, or transferred. The domain name SHALL NOT be included in the zone when in this status. SERVERDELETEPROHIBITED: The registry sets the domain to this status. Requests to delete the domain name MUST be rejected. The domain name can be modified, renewed, or transferred. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. SERVERTRANSFERPROHIBITED: The registry sets the domain to this status. Requests to transfer the domain name MUST be rejected. The domain name can be modified, renewed, or deleted. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. SERVERUPDATEPROHIBITED: The registry sets the domain to this status. Requests to update the domain name (except to remove this status) MUST be rejected. The domain name can be transferred, renewed, or deleted. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. SERVERRENEWPROHIBITED: The registry sets the domain to this status. Requests to renew the domain name MUST be rejected. The domain name can be transferred, deleted, or updated. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. CLIENTHOLD: The registrar sets the domain to this status. The domain name can be updated, renewed, deleted, or transferred. The domain name SHALL NOT be included in the zone when in this status. CLIENTDELETEPROHIBITED: The registrar sets the domain to this status. Requests to delete the domain name MUST be rejected. The domain name can be modified, renewed, or transferred. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. CLIENTTRANSFERPROHIBITED: The registrar sets the domain to this status. Requests to transfer the domain name MUST be rejected. The domain name can be modified, renewed, or deleted. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. CLIENTUPDATEPROHIBITED: The registrar sets the domain to this status. Requests to update the domain name (except to remove this status) Hollenbeck, et al. Expires December 6, 2002 [Page 4] Internet-Draft VeriSign RRP v2.0.0 June 2002 MUST be rejected. The domain name can be transferred, renewed, or deleted. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. CLIENTRENEWPROHIBITED: The registrar sets the domain to this status. Requests to renew the domain name MUST be rejected. The domain name can be transferred, deleted, or updated. The domain SHALL be included in the zone when in this status if the domain has at least one delegated name server. PENDINGDELETE: The registry sets the domain to this status when the registrar successfully completes a DEL command and the domain has not yet been purged from the registry database. Once in this status all registrar requests to act on the domain name MUST be rejected. The registry MAY remove this status and abort the pending purge operation. PENDINGTRANSFER: The registry sets the domain to this status when a request for a transfer is accepted. The domain name cannot be renewed, deleted, or updated when in this status. 2.1.2 Name Server Status Codes OK: This is the default status of a name server. The registry sets the name server to this status. The name server can be updated or deleted. SERVERDELETEPROHIBITED: The registry sets the name server to this status. Requests to delete the name server MUST be rejected. The name server can be modified or renewed. SERVERUPDATEPROHIBITED: The registry sets the name server to this status. Requests to update the name server (except to remove this status) MUST be rejected. The name server can be renewed or deleted. CLIENTDELETEPROHIBITED: The registrar sets the name server to this status. Requests to delete the name server MUST be rejected. The name server can be modified or renewed. CLIENTUPDATEPROHIBITED: The registrar sets the name server to this status. Requests to update the name server (except to remove this status) MUST be rejected. The name server can be renewed or deleted. PENDINGDELETE: The registry sets the domain to this status when the registrar successfully completes a DEL command for the parent domain of the name server and the domain has not yet been purged from the registry database. Once in this status all registrar requests to act on the name server MUST be rejected; delegations to this name server Hollenbeck, et al. Expires December 6, 2002 [Page 5] Internet-Draft VeriSign RRP v2.0.0 June 2002 MUST also be rejected. The registry MAY remove this status and abort the pending purge operation. PENDINGTRANSFER: The registry sets the name server to this status when a request for a transfer of the name server's parent domain is accepted. The name server MAY be deleted or updated when in this status. LINKED: The registry sets the name server to this status when one or more domains have been delegated to the name server. The name server MUST NOT be deleted when in this status. The name server MAY be updated when in this status. 2.1.3 Status Code ABNF Section 7 of RFC 2832 [3] is updated to include the status code changes described in Section 2.1.1 and Section 2.1.2: domainstatus = "OK" / "CLIENTHOLD" / "CLIENTUPDATEPROHIBITED" / "CLIENTDELETEPROHIBITED" / "CLIENTRENEWPROHIBITED" / "CLIENTTRANSFERPROHIBITED" / "SERVERHOLD" / "SERVERUPDATEPROHIBITED" / "SERVERDELETEPROHIBITED" / "SERVERRENEWPROHIBITED" / "SERVERTRANSFERPROHIBITED" / "PENDINGDELETE" / "PENDINGTRANSFER" nameserverstatus = "OK" / "CLIENTUPDATEPROHIBITED" / "CLIENTDELETEPROHIBITED" / "SERVERUPDATEPROHIBITED" / "SERVERDELETEPROHIBITED" / "LINKED" / "PENDINGTRANSFER" / "PENDINGDELETE" 2.2 Response Codes Section 5.1 of RFC 2832 [3] is updated to include two additional error response codes and to modify three existing response codes. 2.2.1 New Response Codes 510 Invalid encoding The value of a domain name or name server entity contains an invalid ASCII compatible encoding used to represent an internationalized domain or host name. The encoding is checked and verified in two situations: when registering an internationalized domain name or name server name, and when changing the name of a name server and the new name of the server is internationalized. Section 5.2 of RFC 2832 [3] is updated to include the addition of response code 510 to the possible error values returned from the ADD Hollenbeck, et al. Expires December 6, 2002 [Page 6] Internet-Draft VeriSign RRP v2.0.0 June 2002 command: Command: ADD Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 535, 540, 541, 545, 546, 547, 549, 550, 554 557 Name server status does not allow for operation The status of the name server does not allow the requested operation. This occurs when a registrar tries to modify a name server that is flagged as CLIENTUPDATEPROHIBITED or SERVERUPDATEPROHIBITED or tries to delete a name server that is flagged as CLIENTDELETEPROHIBITED or SERVERDELETEPROHIBITED. Section 5.2 of RFC 2832 [3] is updated to include the addition of response code 557 to the possible error values returned from the DEL command: Command: DEL Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 533, 541, 544, 545, 547, 549, 551, 552, 553, 557 Section 5.2 of RFC 2832 [3] is updated to include the addition of response codes 510 and 557 to the possible error values returned from the MOD command: Command: MOD Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553, 557 2.2.2 Modified Response Codes 551 Parent domain status does not allow for operation The status of the parent domain does not allow the requested operation. This occurs when a registrar tries to modify a name server whose parent domain is flagged as CLIENTUPDATEPROHIBITED or SERVERUPDATEPROHIBITED or the registrar tries to delete a name server whose parent domain is flagged as CLIENTDELETEPROHIBITED or SERVERDELETEPROHIBITED. 552 Domain status does not allow for operation The status of the domain does not allow the requested operation. Hollenbeck, et al. Expires December 6, 2002 [Page 7] Internet-Draft VeriSign RRP v2.0.0 June 2002 This occurs when a registrar tries to modify a domain that is flagged as CLIENTUPDATEPROHIBITED or SERVERUPDATEPROHIBITED or tries to delete a domain that is flagged as CLIENTDELETEPROHIBITED or SERVERDELETEPROHIBITED or tries to renew a domain that is flagged as CLIENTRENEWPROHIBITED or SERVERRENEWPROHIBITED or tries to transfer a domain that is flagged as CLIENTTRANSFERPROHIBITED or SERVERTRANSFERPROHIBITED. 553 Operation not allowed. Domain pending transfer The status of the domain does not allow the requested operation. The registrar is attempting to delete a domain that is pending approval or denial of a transfer request. The domain is flagged as PENDINGTRANSFER in the registry. 2.3 TRANSFER Command Update Section 4.3.10 of RFC 2832 [3] is updated to include an additional TRANSFER command processing option. Old text: Authorized User: All registrars MAY use the TRANSFER command to request transfer of registration service authority to the requesting registrar. Only the current sponsoring registrar of a domain name may explicitly approve or reject a requested transfer. The registry MAY implicitly approve or reject requested transfers after a fixed amount of time. New text: Authorized User: All registrars MAY use the TRANSFER command to request transfer of registration service authority to the requesting registrar. Only the current sponsoring registrar of a domain name may explicitly approve a requested transfer. The current sponsoring registrar MAY explicitly reject a requested transfer. The registry MAY implicitly approve or reject requested transfers after a fixed amount of time. The requesting registrar MAY cancel a pending request, but the request to cancel the transfer MUST be sent before it has been explicitly approved or rejected by the current sponsoring registrar or it has been implicitly approved or rejected by the registry. Example: A registrar cancels a previously requested domain transfer: Hollenbeck, et al. Expires December 6, 2002 [Page 8] Internet-Draft VeriSign RRP v2.0.0 June 2002 C:transfer C:-Approve:No C:EntityName:Domain C:DomainName:example.com C:. S:200 Command completed successfully S:. 2.4 IPv6 Name Server Addresses Section 7 of RFC 2832 [3] is updated to include support for name servers using IPv6 addresses. IPv6 addressing architecture is described in RFC 2373 [2]. This ABNF grammar supplements the grammar defined in RFC 2832. ; Lexical Tokens hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f doubleoctet = 1*4hexdigit docolon = doubleoctet colon colondo = colon doubleoctet ip-address = ip-address-v4 / ip-address-v6 ; ipv4 addresses ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit ip-address-v6 = ip-address-v6-standard / ip-address-v6-compressed ; Standard form of IPv6 addresses ; 8 hexdigit strings of length 1-4 separated by colons ; ; Eg: 10AA:0:0:00:8:800:200C:417A ip-address-v6-standard = doubleoctet 7colondo ; Compressed form of IPv6 addresses ; Runs of zero-value octets are represented by '::' ; ; Examples: ; :: ==> 0:0:0:0:0:0:0:0 ; Hollenbeck, et al. Expires December 6, 2002 [Page 9] Internet-Draft VeriSign RRP v2.0.0 June 2002 ; 1:: ==> 1:0:0:0:0:0:0:0 ; 2:2:: ==> 2:2:0:0:0:0:0:0 ; 7:7:7:7:7:7:7:: ==> 7:7:7:7:7:7:7:0 ; ; ::1 ==> 0:0:0:0:0:0:0:1 ; ::2:2 ==> 0:0:0:0:0:0:2:2 ; ::7:7:7:7:7:7:7 ==> 0:7:7:7:7:7:7:7 ; ; E::1 ==> E:0:0:0:0:0:0:1 ; E::2:2 ==> E:0:0:0:0:0:2:2 ; E::6:6:6:6:6:6 ==> E:0:6:6:6:6:6:6 ; ; E:E::1 ==> E:E:0:0:0:0:0:1 ; E:E::2:2 ==> E:E:0:0:0:0:2:2 ; E:E::5:5:5:5:5 ==> E:E:0:5:5:5:5:5 ; ; E:E:E::1 ==> E:E:E:0:0:0:0:1 ; E:E:E::2:2 ==> E:E:E:0:0:0:2:2 ; E:E:E::4:4:4:4 ==> E:E:E:0:4:4:4:4 ; ; E:E:E:E::1 ==> E:E:E:E:0:0:0:1 ; E:E:E:E::2:2 ==> E:E:E:E:0:0:2:2 ; E:E:E:E::3:3:3 ==> E:E:E:E:0:3:3:3 ; ; E:E:E:E:E::1 ==> E:E:E:E:E:0:0:1 ; E:E:E:E:E::2:2 ==> E:E:E:E:E:0:2:2 ; ; E:E:E:E:E:E::1 ==> E:E:E:E:E:E:0:1 ip-address-v6-compressed = colon colon ip-address-v6-compressed =/ 1*7docolon colon ip-address-v6-compressed =/ colon 1*7colondo ip-address-v6-compressed =/ docolon 1*6colondo ip-address-v6-compressed =/ 2docolon 1*5colondo ip-address-v6-compressed =/ 3docolon 1*4colondo ip-address-v6-compressed =/ 4docolon 1*3colondo ip-address-v6-compressed =/ 5docolon 1*2colondo ip-address-v6-compressed =/ 6docolon colondo 3. Internationalization Considerations This document does not introduce any new internationalization considerations that are not already documented in RFC 2832 [3]. 4. IANA Considerations This document does not introduce any new IANA considerations that are Hollenbeck, et al. Expires December 6, 2002 [Page 10] Internet-Draft VeriSign RRP v2.0.0 June 2002 not already documented in RFC 2832 [3]. 5. Security Considerations This document does not introduce any new security considerations that are not already documented in RFC 2832 [3]. 6. Acknowledgements The authors graciously acknowledge the contributions of John Brady, Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. [3] Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar Protocol (RRP) Version 1.1.0", RFC 2832, May 2000. Informative References [4] Hollenbeck, S., "Extensible Provisioning Protocol", draft-ietf- provreg-epp-06 (work in progress), January 2002. [5] Hollenbeck, S., "Extensible Provisioning Protocol Domain Name Mapping", draft-ietf-provreg-epp-domain-04 (work in progress), January 2002. [6] Hollenbeck, S., "Extensible Provisioning Protocol Host Mapping", draft-ietf-provreg-epp-host-04 (work in progress), January 2002. URIs [7] Hollenbeck, et al. Expires December 6, 2002 [Page 11] Internet-Draft VeriSign RRP v2.0.0 June 2002 Authors' Addresses Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: shollenbeck@verisign.com Srikanth Veeramachaneni VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: sveerama@verisign.com Suresh Yalamanchilli VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US EMail: syalamanchilli@verisign.com Appendix A. Appendix A: Change History (Note to RFC editor: please remove this section completely before publication as an RFC.) The following changes were made to produce version -01 from -00: o Editorial fixes throughout. o Added Section 2.1. o Updated Section 2.2. o Fixed typos in IPv6 address examples given in Section 2.4. Hollenbeck, et al. Expires December 6, 2002 [Page 12] Internet-Draft VeriSign RRP v2.0.0 June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hollenbeck, et al. Expires December 6, 2002 [Page 13]