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

Registry Advantage will provide an RRP interface to the Shared Registry System (SRS) throughout the transition period.  A full description of this protocol is defined in RFC 2832 and is included as Attachments P1.  At the time of this proposal, VeriSign is contemplating a number of changes to the RRP, as described in an Internet-Draft written by Scott Hollenbeck [1] .  These changes include:

• Status codes for registry entities have been modified to be more similar to those used in EPP.
• Clients have the capability to cancel a requested transfer.
• IPv6 name server addresses are supported.
• Some response codes have been added or modified.

The adoption of these changes would result in the RRP version being updated to 2.0.0.  Registry Advantage 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 Attachment P1

In addition to implementing protocol elements identical to those used within VeriSign’s SRS, DotOrg Foundation 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, DotOrg Foundation intends to allow registrars to continue regular business operations with the least possible disruption from 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 [2] , to create a generic registry-registrar protocol that would be applicable to a wider 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. Registry Advantage strongly supports the creation of this standard, and intends to work as part of any collaborative process to create such a protocol.  In addition to its RRP interface, Registry Advantage 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 [3] .  Registry Advantage has currently implemented this version of the EPP drafts for use by its ccTLD registries.

Additional details of the Registry Advantage protocol implementation are provided in Question C17.2 above.

Transition from RRP to EPP

Although DotOrg Foundation 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:

• Registrant information
• Administrative and technical contact information
• Qualifications to register a .org domain name
• Additional information for the DotOrg Directory [OPTIONAL]

The thick registry model conveys several advantages.  First, 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.  Second, registrars are not burdened by the necessity to maintain potentially costly Whois infrastructure, although they may choose to do so.  Third, a thick registry offers the opportunity to significantly streamline inter-registrar functions, such as transferring domains between registrars.  The registrar community is currently engaged in broad-ranging discussions regarding transfers and other issues, and DotOrg Foundation believes that the eventual outcome of those discussions will be invaluable in devising clear practices for both registries and registrars.  DotOrg Foundation expects that it will be able to leverage its thick registry model to provide more efficient services to registrars as a result of these discussions, and 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.

The RRP does not support thick registry data; as a result, its use will be gradually phased out.  In order to provide registrars with an easy transition from RRP to EPP, Registry Advantage will work with the registrar community and ICANN to develop a specific schedule for this transition, and will establish specific milestones that must be met prior to moving to the next phase of the transition.  Registry Advantage has developed the following schedule as an indication of the preferred approach to this transition and to provide general guidance in terms of scheduling.

Pure Thin Registry Operations

Immediately upon the transition of registry operations from VeriSign to DotOrg Foundation, the registry will continue to be operated purely as a thin registry.  Although DotOrg Foundation will allow registrars to make use of the EPP protocol, which has the capability of transmitting social data, only thin registry data elements will be allowed through either RRP or EPP.

This pure thin registry operation will continue for approximately three months.  This period is intended to allow DotOrg Foundation to familiarize the Internet community with the new registry’s 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.

Optional Thick Registry Data

Beginning on or about April 15, 2003, DotOrg Foundation’s EPP interface will begin allowing social data to be optionally associated with .org domain names.  At least one month prior to this, the OT&E environment will also be modified to also allow for the optional use of social data.  Specifically, the .org EPP implementation will be modified to allow contact objects to be optionally associated with domain objects.

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.

New Registrations and Renewals Require Social Data

Approximately six months after social data is optionally allowed by the registry, on or about October 15, 2003, DotOrg Foundation will begin requiring that registrars provide social data for all new .org registrations.  Additionally, domains will not be renewed unless they have social data applied to them; this requirement applies both to domains that are explicitly renewed through the use of the renew command as well as domains that would otherwise be automatically renewed. 

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.  DotOrg Foundation suggests that the RRP be discontinued approximately six months after the transition of registry operators, on or about July 15, 2003.

Social Data Required For Active Domains

Approximately one year after requiring that new and renewed domains include social data, the registry will begin to notify registrars of any domains they sponsor that remain in the registry but do not include social data.  These notices will be provided monthly, on or about October 1, November 1 and December 1, 2004.  One month after the final notice is sent to registrars, on January 1, 2005, any domain without social data will be removed from the .org zone file.  These domains will remain in the registry database for a period of six months; once the registrar updates them to include social data, they will once again be published into the zone file.

Pure Thick Registry

Six months after the requirement of zone data for all active domains is implemented, DotOrg Foundation will require social data for all domains within the registry database.  Any domains that remain in the registry database without associated social data will be deleted as of July 1, 2005.  At this point, the registry will be operating purely as a thick registry and the thin to thick registry will be completed.

A summary of the major events in the transition between the use of RRP and EPP is provided in the chart below:

Figure C22.1 RRP/EPP Transition Timeline

Toolkit

In order to assist registrars in connecting to the SRS, Registry Advantage will provide a registrar toolkit (RTK). The RTK is a software development kit that will support the development of a registrar software system for registering domain names within the registry using the RRP.  The RTK will consist of both software and documentation elements.  Although the specific components of the RTK are subject to change, the initial makeup of the toolkit will include:

• Documentation describing the details of both EPP and RRP protocols.
• Documentation describing the registry’s registration policies.
• Documentation relating to DotOrg Foundation’s customer service, including contact and escalation information.
• C++ libraries providing registrars with an API.
• Java libraries providing registrars with an API.
• Documentation describing the APIs and their use.
• Sample code providing registrars with an example of how to make use of the APIs and perform various functions in the SRS.

Registry Advantage currently offers both 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 DotOrg Foundation; additionally, some specific software and documentation will need to be created to support the RRP interface to the SRS.

In order to make the transition from RRP to EPP as straightforward as possible, Registry Advantage will provide additional documentation during the transition describing the differences between the protocols, and will attempt to make the APIs for both protocols as similar as is practical.  Registry Advantage 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 TEST environment, 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 as well as other platform and language support.

TEST Systems

Throughout the transition, and on an ongoing basis, Registry Advantage will provide registrars with access to the Testing Environment, Support and Training(TEST) systems, which allow them to test their SRS client implementations in an environment that is functionally identical to the live SRS.  The TEST systems will provide registrars with both RRP and EPP interfaces to allow them to fully test both legacy systems as well as systems that will connect to the new EPP interface.