Generic Top-Level Domain (gTLD) Registry Agreements
Proposed Unsponsored TLD Agreement: Appendix C, Part 2 (.name)
|
Part 2 - Shared Registration System Protocol and Interface Overview The Registry Operator will implement a "thick" Registry, storing information about domain names; e-mail forwarding; defensive registrations; nameservers; registrants; administrative, technical, and billing contacts; and registrars. As the commonly used "NSI Registry Registrar Protocol (RRP) Version 1.1.0", as specified in RFC 2832, only supports a "thin" Registry model, another protocol needs to be used that can also manage social information (e.g., contacts). Since November 2000, Scott Hollenbeck of Verisign Global Registry Services has worked on an XML-based protocol that supports both a "thin" and a "thick" Registry model. The protocol, "Extensible Provisioning Protocol" (EPP), is now being developed through the IETF "provreg" working group and it expects to have a draft for a standards track protocol in September 2001. The Registry Operator will provide access to a restricted Registry-Registrar interface service based on EPP, as specified in the Hollenbeck EPP drafts. As the drafts-work is still in progress, the Registry Operator will initially implement the as-of-today latest version of the specification, the "-04/-02"-versions of the EPP-drafts. To achieve this, and to facilitate logging and verification of both system performance and functionality, as well as the fairness requirement, the system will log each transaction as received by the protocol implementations. The system will then repackage each transaction request into a message format internal to the Registry Operator's system, and common to all protocol implementations in use at the time by the Registry Operator. Said message will then be transmitted to the Registry Operator's internal queue using a queuing algorithm that will be documented as part of the system development process, and that will be available to ICANN upon request and verifiable in conformance with Appendix I. An application will service the queue and log any transaction start. It will then proceed to execute all requests needed against the database to either successfully complete the transaction or determine absolutely that the transaction in question can not be completed as submitted. The result will be logged to the transaction log and then be submitted back to the protocol implementation. In the case of a successful transaction the update will further be transmitted to the Registry Operator's Whois and DNS subsystem for distribution to all Whois and DNS servers. Such transmission will, under normal operation, be processed in near real-time (see performance specification in Appendix D). Specification The Registry Operator will implement EPP as specified in the latest "-04/-02"-versions of the EPP-drafts. Additional data may be supported if the Registry Operator allows Registrars to store additional data or enable additional services in the future. In the event that the Registry Operator wishes to make such additions, Registry Operator shall comply with Appendix C, Part 7 (Patch, Upgrade & Update Policy) and ICANN will be advised of said additions a reasonable time in advance. The EPP specification is broken up into an extensible object design with the specific objects given a consistent interface (mapping) that meet the base EPP framework as described below. The specifications are attachments to this Appendix C: Base EPP description: Latest version: draft-ietf-provreg-epp-04.txt EPP TCP Server: Latest version: draft-ietf-provreg-epp-tcp-02.txt EPP Domain mapping: Latest version: draft-ietf-provreg-epp-domain-02.txt EPP Host (Nameserver) mapping: Latest version: draft-ietf-provreg-epp-host-02.txt EPP Contact mapping: Latest version: draft-ietf-provreg-epp-contact-02.txt EPP Email Forwarding mapping: Latest version: epp-emailforwarding-03.txt (not an Internet draft) Supported Command Set The following commands are supported by the EPP:
Note that for domain name and SLD E-mail registrations and Defensive Registrations, the object can only be registered or renewed in integer number of years, with minimum and maximum values of one and ten years, respectively. The maximum outstanding expiration period is restricted to ten years. More information about the commands and examples of their usage can be found in the relevant EPP-drafts mentioned above. Implementation of Provreg Proposed Standard(s) The Registry Operator will implement support for the IETF provreg working group's protocol specification within 135 days of its adoption as a Proposed Standard [RFC 2026]. Registrations of domain names, SLD E-mail forwarding addresses, and Defensive Registrations and, to the extent practical, the NameWatch Service, will employ the Proposed Standard (where applicable by its terms) or a derivative of that standard (where the Proposed Standard is not directly applicable). At any time when the Registry Operator wishes to make functional updates to its protocol implementations or remove existing implementations, notice will be given to ICANN and Registrars a reasonable time in advance, in compliance with Appendix C, Part 7 (Patch, Upgrade & Update Policy), and Registry Operator will otherwise meet the requirements of its Registry Agreement with ICANN. Operating parameters The SRS Protocol and other protocols used to interact with the Registrars for the purpose of registering domains are critical to the Registry Operator, and, as such, all care will be taken to ensure a high degree of stability and continued operation. Reporting Transactions in the SRS Interface will be subject to reporting as per Appendix T. Additional reports may be generated as needed for internal auditing and operations management. Security Security of the SRS Protocol service will be provided in part via the mandatory use of the SSL protocol for transport layer security and in part by the use of an optional VPN as an additional layer of security. Apart from this, the SRS Protocol service will be subject to the Registry Operator's general security standards.
Comments concerning the layout, construction and functionality of this site should be sent to webmaster@icann.org.
|
