C17.2. Registry-registrar model and protocol. Please describe in detail, including a full (to the extent feasible) statement of the proposed RRP and EPP implementations. See also item C22 below.

A "thin" registry-registrar model is currently used for the .org registry. In this model, information associated with each registered domain name is distributed between the registry and the sponsoring registrar. The registry maintains delegation information needed to publish the .org zone, while the registrar maintains information describing the registrant and other contacts (such as technical, administrative and billing contacts) associated with the domain. The NSI Registry-Registrar Protocol (RRP) (described in RFC 2832) is used to exchange information between registrars and the .org registry in real time. Registrants register and manage domain name information through one of several ICANN-accredited registrars.

A "thick" registry model is one in which the registry maintains copies of all information associated with registered domains, including registrant and contact information. Registrars typically maintain their own copies of registration information, thus registry-registrar synchronization is required to ensure that both registry and registrar have consistent views of the technical and social information associated with registered domains. The Extensible Provisioning Protocol (EPP), first published by VGRS and later adopted by the Internet Engineering Task Force (IETF) provreg working group, provides features to support both thick and thin registry models.

The basic registrant-registrar-registry model for the .org gTLD has become familiar and stable over the course of three years of ongoing operations. The UIA Team will preserve the "thin" registry model as-is, initially continuing support for RRP while gradually transitioning to a "thin" registry served by the Extensible Provisioning Protocol.

Continued use of RRP at the outset of registry operations provides several advantages that help preserve the stability of the .org gTLD:

  • Registrars have gained significant operational and business logic experience with RRP. Initial use of RRP using the existing VGRS infrastructure ensures that transition risk is absolutely eliminated.

  • VGRS has been able to optimize its RRP implementation to the point of being able to support peaks of more than 150 million transactions per day, and a sustained daily average of more than 130 million transactions per day. No other registry operator has demonstrated similar processing capabilities with RRP.

  • EPP is not yet an IETF proposed standard. There is significant risk in deploying an implementation of EPP before the first proposed standards are published as the protocol is still evolving, and revisions mean code changes for both registry and registrars.

  • RRP is stable. Initial use of RRP will allow for initial registry operations that have no timetable dependencies on the development of EPP.

  • Both registries and registrars are still gaining experience with EPP. Initial implementations are likely to have defects and performance limitations that can only be discovered and corrected over time.

The UIA Team will use the existing VGRS RRP implementation, designed and developed by the original authors of the protocol, at the start of registry operations. This implementation has been refined, optimized and tailored to ICANN processes over the course of three years of high-pressure, high-volume registry operations, providing registrars with levels of real-time service and performance unmatched in the domain name industry. Satisfactory levels of stability, reliability and error-free performance are guaranteed with this implementation of RRP.

While initial use of RRP provides significant stability advantages at the start of registry operations, support for EPP is required in the future. EPP includes many features and improvements that help make the transition possible and worthwhile, including:

  • Extensibility (adding new features, such as support for ENUM and DNS security) gained through the use of XML and a well-defined protocol extension mechanism,
  • Multiple transport protocol options,
  • Improved features to authenticate and streamline transfer operations,
  • Real-time client notification and message queuing,
  • Support for IPv6 name server addresses,
  • Improved pre-sales query mechanisms, and
  • Specification refinement and eventual standardization through the open processes of the IETF.

VGRS has been developing implementations of EPP for several months, and has already released an implementation for the provisioning of Internet keywords based on Internet-Draft EPP specifications. An active project to develop an implementation for use in the .com and .net registries has been following the ongoing efforts of the IETF's provreg working group, with finalization and deployment planning dependent on the publication of proposed standards by the IETF.

Our early implementations of EPP have already been subjected to several rounds of development and formal quality assurance testing. With protocol stability and transition costs being a significant concern in the ongoing management of .org, the UIA team will fully deploy an implementation of EPP only after the IETF has published Proposed Standard protocol documents. Free client Software Development Kits (SDKs) that interoperate with other EPP servers will be available in multiple programming languages to minimize the amount of software development required of registrars. An isolated Operational Test & Evaluation (OT&E) environment will be available for registrar testing prior to "live" operations, allowing registrars to develop and test their software systems with no risk to "live" data or systems. Issues, defects, and errors noted during OT&E testing will be corrected rapidly and deployed in both the OT&E and "live" environments, ensuring that both environments use the exact same software code bases and that transition will require little more than minor changes to client configuration parameters.

A detailed description of the transition plan for retiring RRP and deploying EPP can be found in Section C22


Back to Table of Contents