en

Generic Top-Level Domain (gTLD) Registry Agreements

gTLD Registry Agreements establish the rights, duties, liabilities, and obligations ICANN requires of registry operators to run gTLDs.

Proposed Unsponsored TLD Agreement: Appendix C, Part 2 (.name)

ICANN | Proposed Unsponsored TLD Agreement: Appendix C, Part 2 (.name)

  ICANN Logo

Proposed Unsponsored TLD Agreement: Appendix C,

Part 2 (.name)

(2 July 2001)


Functional Specifications

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.
The Registry Operator will implement EPP and future protocols, in such a manner that these protocols will act as a frontend for the registry system and will be easy to replace. The protocol implementations will handle connections and transactions from all ICANN-Accredited Registrars on an equal basis, as specified in the Registry Agreement and the Registry Operator's Code of Conduct (Appendix I).

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
This document describes a connection-oriented, application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects.

EPP TCP Server:

Latest version: draft-ietf-provreg-epp-tcp-02.txt
This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a single Transmission Control Protocol (TCP) connection. This mapping requires use of the Transport Layer Security (TLS) Protocol to protect information exchanged between an EPP client and an EPP server.

EPP Domain mapping:

Latest version: draft-ietf-provreg-epp-domain-02.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet domain names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to domain names.

EPP Host (Nameserver) mapping:

Latest version: draft-ietf-provreg-epp-host-02.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Internet host names stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to host names.

EPP Contact mapping:

Latest version: draft-ietf-provreg-epp-contact-02.txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of individual or organizational social information identifiers (known as "contacts") stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to contacts.

EPP Email Forwarding mapping:

Latest version: epp-emailforwarding-03.txt (not an Internet draft)
This document describes an Extensible Provisioning Protocol (EPP) mapping for the provisioning and management of Email Forwarding objects stored in a shared central repository. Specified in XML, the mapping defines EPP command syntax and semantics as applied to Email Forwarding objects. The Email Forwarding service is described in detail in the "Email forwarding" section elsewhere in Appendix C.

Supported Command Set

The following commands are supported by the EPP:

  Command Description
Session Management Commands <login> Establish a session with a server
  <logout> End a session with a server
Object Query <check> Determine if an object is known to the server
  <info> Retrieve detailed information associated with a known object
  <poll> Receive service notifications from the server
  <transfer> Retrieve object transfer status information
Object Transform <create>

Create an instance of an object with a server
  <delete> Remove an instance of an object from a server
  <renew> Extend the validity period of an object
  <transfer> Manage changes in client sponsorship of a known object
  <update> Change information associated with an object
     

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.
Multiple instances of the protocol implementations will operate on separate servers to provide an active/active fail-over mechanism. Each instance of the protocol implementations will be independent and any one server may fail without disrupting any protocol implementations running on other servers.

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.

Page Updated 03-Jul-2001

(c) 2001  The Internet Corporation for Assigned Names and Numbers. All rights reserved.