Main Page | Proposal Home
Jump to question:
C1 | C2 | C3 | C4 | C5 | C6 | C7 | C8 | C9 | C10 | C11 | C12 | C13 | C14 | C15 | C16 | C17 | C18 | C19 | C20 | C21 | C22 | C23 | C24 | C25 | C26 | C27 | C28 | C29 | C30 | C31 | C32 | C33 | C34 | C35 | C36 | C37 | C38 | C39 | C40 | C41 | C42
C22. VeriSign, Inc., the current operator of the .org registry uses a registry-registrar protocol (RRP) documented in RFC 2832. At the time of the transition, the selected successor operator will be required to continue to support the RRP (unless a migration of registrars in .org to another protocol has already been completed by that time). In addition, the selected successor operator will be required to implement support for the IETF provreg working group's protocol specification for an Extensible Provisioning Protocol (EPP) no later than 135 days after it is adopted as a Proposed Standard [RFC 2026, section 4.1.1]. Provide a detailed description of your plan for supporting RRP at the time of transition, for supporting EPP within the required time frame, and for providing registrars with a smooth, low-cost migration path from RRP to EPP.
RRP and EPP Protocol Support
The adoption of these changes would result in the RRP version being updated to 2.0.0. The Registry’s technical team will implement the same version of the RRP protocol as VeriSign expects to be using on December 31, 2002, and anticipates that this version is likely to be 2.0.0. Both the current version (1.1.0) and proposed version (2.0.0) of VeriSign’s RRP are included as an Attachment in Section XI (Protocol Details: RRP).
In addition to implementing protocol elements identical to those used within VeriSign’s SRS, the Registry’s technical team has duplicated many of the existing policies and procedures, such as those related to grace periods and transfers, used by the .org registry. By providing registrars with consistency in both technical interface and business logic throughout the transition period, RegisterOrg intends to allow registrars to continue regular business operations with the least possible disruption due to the migration of registry operation.
Unfortunately, the RRP provides only a limited set of functionality and is rapidly becoming an outdated, proprietary protocol associated only with VeriSign’s gTLD registry operations. In 2001, the Internet Engineer Task Force (IETF) formed a working group, known as provreg , to create a generic registry-registrar protocol that would be applicable to a wide range of domain name registries. This working group has created a number of Internet drafts for the Extensible Provisioning Protocol (EPP), including one describing the requirements for a generic registry-registrar protocol and several others describing the core EPP protocol as well as specific domain, name server, and contact object types. The Registry and its technical team strongly support the creation of this standard, and intend to work as part of any collaborative process to create such a protocol. In addition to its RRP interface, the Registry’s system will provide an EPP interface for registrars from the inception of its SRS service, and will eventually discontinue the use of the legacy RRP protocol in favor of EPP. As EPP is currently an evolving protocol, the specific version and details may be subject to change between the time of this proposal and the actual implementation, but the current candidate protocol is EPP-06/04. The Registry’s technical team has currently implemented this version of the EPP drafts for use by its ccTLD registries.
Additional details of the protocol implementation are provided above in Section C17.2.
Transition from RRP to EPP
Although the Registry will initially operate a “thin” .org registry in the same manner that VeriSign does today, the registry will eventually be expanded to allow for a “thick” set of registry data. This will be accomplished via a stable transition plan, described in Question C18. Specifically, .org will gather the following information that is not included in the current gTLD registry:
The thick registry model conveys three advantages :
1. A centralized source of public information, such as a Whois database, offers the Internet community a single resource with complete, standardized information about each domain name.
The registrar community is currently engaged in broad-ranging discussions regarding transfers and other issues, and RegisterOrg believes that the eventual outcome of those discussions will be invaluable in devising clear practices for both registries and registrars. RegisterOrg expects that, as a result of these discussions, it will be able to leverage its thick registry model to provide more efficient services to registrars, and Register.com awaits the formation of a consensus by all involved parties.
Slightly different EPP implementation will be required during initial operation as a “thin” registry and later as a “thick” registry. The principal difference is that the thin registry operation incorporates no social data. EPP’s separation of registration events into domain, contact and name server objects makes this straightforward. A thin registry simply does not allow for contact objects to be created or associated with domain names. EPP also allows for migration of the registry from thin to thick.
I. Pure Thin Registry Operations
This pure thin registry operation will continue for approximately three months. This period is intended to allow the Registry and its technical team to familiarize the Internet community with the new systems, to correct any minor problems that may have been identified during the transition of registry operator, and to allow a thorough analysis of data integrity to be performed.
II. Optional Thick Registry Data
This mode of operation will allow registrars to become more familiar with the thick registry model, without requiring that they immediately begin to provide social data for all registrations. Additionally, those registrars with existing EPP interfaces to other thick registries such as .info, .biz, and .name will be able to begin interacting with .org in a similar manner to those other registries.
III. New Registrations and Renewals Require Social Data
In anticipation of this requirement, the RRP interface to the SRS, which does not allow for the transmission of social data, will be phased out. RegisterOrg suggests that the RRP be discontinued approximately six months after the transition of registry operators, on or about July 15, 2003.
IV. Social Data Required For Active Domains
V. Pure Thick Registry
A summary of the major events in the transition between the use of RRP and EPP is provided below:
Although the specific components of the RTK are subject to change, the initial makeup of the toolkit will include:
The Registry’s technical team currently offers toolkits for both its EPP and proprietary SRP interfaces. These toolkits will form the basis for the RTKs provided to registrars, although some modifications will need to be made to reflect the specific requirements and policies of the Registry. Also, the Registry will create additional software and documentation specifically to support the RRP interface to the SRS.
In order to make the transition from RRP to EPP as straightforward as possible, the Registry’s technical team will provide additional documentation during the transition. The documentation will describe the differences between the protocols, and will attempt to make the APIs for both protocols as similar as is practical. The Registry will also interact with the registrar community, in order to discover whether any additional software or documentation would make the transition more straightforward.
The RTK can be used by the registrar as a basis for connecting to the Testing Environment, Support and Training (TEST) environment (see below), and can be used to develop a system for interfacing with the live registry once the registrar has been certified. The RTK will remain under continuous development and will provide support for additional features as they become available—including other platform and language support.
[previous question] [next question]