RRP and EPP Protocol Support
The Registry’s systems 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 an Attachment in Section XI (Protocol Details: RRP). 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 . These changes include:

· Modification of status codes for registry entities, in order to make them more similar to those used in EPP;
· Capability of clients to cancel a requested transfer;
· Support of IPv6 name server addresses; and.
· Addition or modification of some response codes.

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:

· Registrant information;
· Administrative and technical contact information.

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.
2. Registrars are not burdened by the necessity to maintain potentially costly Whois infrastructure, although they may choose to do so.
3. 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 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.

Transition Schedule
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, the Registry 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. The following schedule has been developed as an indication of the preferred approach to this transition and to provide general guidance in terms of scheduling.

I. Pure Thin Registry Operations
Immediately upon the transition of registry operations from VeriSign to RegisterOrg, the registry will continue to be operated purely as a thin registry. Although RegisterOrg 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 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
Beginning on or about April 15, 2003, the Registry system’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 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.

III. 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, RegisterOrg 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 and to 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. 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
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.

V. Pure Thick Registry
Six months after the requirement of zone data for all active domains is implemented, RegisterOrg 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 below:

Registrar Toolkit
In order to assist registrars in connecting to the SRS, the Registry’s technical team 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 RegisterOrg’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; and
· Sample code, providing registrars with an example of how to make use of the APIs and perform various functions in the SRS.

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.

TEST Systems
Throughout the transition, and on an ongoing basis, the Registry 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, allowing them to fully test both legacy systems as well as systems that will connect to the new EPP interface.