IV.  Provisions for Equivalent Access by Accredited Registrars

C20. The selected successor operator for the .org registry will be required to provide all ICANN-accredited registrars having registry-registrar agreements in effect with equivalent access to registry services through a shared registry system, under which those registrars will provide services (either directly or through resellers) to registrants. This section of the .org Proposal covers the applicant's proposed arrangements for interacting with registrars in a manner that provides equivalent access.

C21. Describe in detail your proposed methods of providing registry services on an equivalent basis to all accredited registrars having registry-registrar agreements in effect. Your description should include any measures intended to make registration, technical assistance, and other services available to ICANN-accredited registrars in different time zones and relevant languages. In addition, describe the Registry Code of Conduct and other commitments you propose to make to ensure that all such registrars receive equivalent access to registry services. In preparing your response to this item, you may wish to refer to Appendices H and I of the registry agreements ICANN has entered for unsponsored TLDs (e.g., .biz, .com, .info, .name, and .pro).

The UIA Team will ensure that all Registry Services are made available to every operational ICANN-accredited registrar in an equivalent manner through the use of efficient operational and technical processes, as well as response/escalation procedures to address any challenges. The processes include: certification of registrars, customer support, registry Code of Conduct assurance, and technical elements of equivalent access.

Certification of Registrars

To date, more than 100 registrars have been successfully certified to register .org domain names. The UIA Team intends to build upon this means of promoting registrar competition by implementing a simple, efficient method of preparing new registrars for production. Some key features of this process are:

  • Consistent application of all criteria used in this process for all registrars, as documented in ramp-up files.

  • Initial welcome packages, containing detailed explanation of all required steps and technical resources, mailed overnight within 24 hours of receipt of ICANN notice that registrar has achieved accreditation. Once registrar returns signed Confidentiality Agreement, it may complete all remaining steps in any order it chooses. These steps include contact information sheet, executed Registry-Registrar Agreements, corporate formation documents, surety instrument, payment security, credit information and technical certification.

  • Contract administrators to manage the entire process across various functional groups within the UIA Team. The process is coordinated through a document/information management system in which steps are recorded so that each group can monitor progress and ensure consistent and timely completion for all registrars.

  • Availability of UIA customer and technical support for the registrar during technical testing and all other phases.

  • Regular contact between the registrar and the UIA Team to provide status updates and offer any assistance in fulfilling the requirements.

Customer Support

The UIA Team believes that superior, prompt customer support to all registrars is an essential element to the success of the .org TLD. In this regard, Diversitas plans to provide:

  • 7x24x365 customer support through a team of trained customer service representatives.

  • Representatives available to address questions and assist customers in every time zone at the customer's convenience.

  • Use of Language Line, a telephone translation service also available 7x24x365, enables the UIA Team to communicate effectively and immediately with all of its customers without additional expense to the customer.

  • Established escalation procedures whereby technical, legal or other high-level issues are promptly forwarded to the appropriate groups, ensuring suitable, professional, and timely responses.

Registry Code of Conduct

The Registry Code of Conduct contained in Appendix I of the existing unsponsored TLD Registry Agreements serves as a model of superior business practices. As referred to in Section C19 hereof, the UIA Team will develope a training course for all relevant employees and contractors. As is the intent of the Code of Conduct, the fundamental theme of the training course is avoiding and preventing preferential treatment of any ICANN-accredited registrar. At the conclusion of each course, all participants will be required, as a material condition of employment, to execute an Organizational Conflict of Interest (OCI) Avoidance Certification that certifies their agreement to avoid conflicts and to report any potential conflicts. This course will also contain:

  • A detailed policy regarding proper use and dissemination of confidential and sensitive information and data, to be distributed during the course and at various other times throughout the year. Participants are further instructed on the proper methods of safeguarding and destroying such material.

  • An Information Control Matrix, a document governing which employees or group of employees are entitled to which type of information. The OCI course emphasizes that sensitive information is distributed only to those employees or contractors having a legitimate need to know for purposes of performing their job function.

  • A detailed review of the Code of Conduct, as well as all items contained in the Equivalent Access Certification (Appendix H to existing non-sponsored TLD Registry Agreements).

UIA will implement this OCI program for all personnel providing support to the UIA Team for the .org TLD. A Compliance Officer who will be a member of the Diversitas staff will manage the compliance program.

As an additional means of monitoring compliance with the Code of Conduct and the Equivalent Access Certification, Diversitas plans to continue the use of periodic reviews and department surveys conducted by the Policy and Compliance group. As highlighted in Section C19 of this proposal, these surveys, recorded in written form and kept on file, are intended to provide evidence that each of the equivalent access requirements in Appendix H of the .org registry agreement are being met.

Technical Elements of Equivalent Access

As discussed in detail in Section C17.10, the UIA Team has implemented a system whereby each operational registrar is assured equivalent access to the SRS through its use of connections to the various pools: the Guarantee Pool, Overflow Pool, and finally, the Automated Batch Pool. This system recognizes and appreciates the various business models utilized by registrars while at the same time providing a fair and level playing field. 

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.

As described in section C.17.2, the UIA Team will support the Registry Registrar Protocol (RRP) described in RFC 2832 at the start of registry operations. The existing VGRS implementation of RRP will be used to ensure that initial operations will not be subject to extended outages due to load or new software implementation defects. Additionally, existing registrar software systems will be able to function without any significant change, ensuring that initial registrar costs are minimized and reliability is assured.

Support for EPP will be phased in gradually. Though the IETF has not yet produced proposed standards for EPP, VGRS has been developing an implementation of the protocol using existing Internet-Draft documents to minimize the amount of time required to support the protocol once proposed standards are finally published. The VGRS implementation of EPP is being developed to the same exacting standards of reliability and performance required of the .com and .net registries, and the lengthy (but deliberate) development effort will ensure that the implementation is sound and ready for production deployment in the future.

Support for RRP will be eliminated only after support for EPP has been introduced and a lengthy period of parallel operations has been completed. A complete migration to EPP will allow registry and registrars to support a single provisioning protocol stack, allowing each to simplify operations and reduce costs. Newly accredited registrars will have ample opportunity to develop an implementation of EPP.

The transition process and timeline is illustrated in Figure C22.

Figure C22: RRP to EPP Transition Process

  1. RRP will be used at the start of registry operations to minimize the transition impact for registrars. EPP implementation based on Internet-Draft documents will continue in preparation for implementation and deployment based on proposed standard documents.
  • Transition from RRP to EPP requires the existence of proposed standards for EPP. If proposed standards exist at the start of registry operations, transition efforts will begin immediately. If proposed standards do not exist at the start of registry operations, the formal transition process will begin when proposed standards are formally announced by the IETF.
  1. Within 135 days of proposed standards for EPP being announced by the IETF (or within 135 days after the start of registry operations if proposed standards exist at the start of registry operations), EPP will be made available to registrars for development and testing in an Operational Test & Evaluation (OT&E) environment. The OT&E environment will allow registrars and the registry to fine tune their protocol implementations before beginning live operations.
  •  UIA will continue to maintain a "thin" registry for .org. Transition to a "thick" registry would require a costly and error-introducing migration of data from the registrars to the registry, whereas continuing the "thin" .org registry preserves current registrar operating models, doesn't require registrars to archive and deliver registrant and contact data to the registry, and eliminates the possibility of introducing data consistency errors as part of populating a "thick" registry.
  1. 90 calendar days after the introduction of EPP in the OT&E environment, both EPP and RRP will be supported in the "live" production environment. Both protocols will be available to access the same data sets, ensuring that inter-registrar data views remain consistent and independent of the protocol being used by any particular registrar. The OT&E environment will remain available on an ongoing basis for development and testing.
  1. Support for both EPP and RRP will continue during a minimum parallel operations period of 90 calendar days. The parallel operations period may be extended as needed to ensure that the transition is proceeding smoothly and the stability of the .org registry is maintained.
  2. Support for RRP will be terminated at the end of the parallel operations period.

Transition to EPP will impact both the .org registry and the registrars of .org domains. The UIA Team will take several steps to help provide a smooth, low-cost migration path from RRP to EPP, including:

  • Providing initial support for RRP to take full advantage of existing registrar software systems;

  • Providing support for a development and test environment where registrars and registry can test new software systems prior to "live" operations;

  • Participation in open source software development efforts to produce an EPP client software development kit for use with the .org registry and other registries that support EPP;

  • Providing a lengthy period of parallel operations to ensure that EPP implementations are working properly, and

  • Eventual elimination of support for RRP so that the registry and registrars can both optimize implementations of a single provisioning protocol stack rather than having to maintain dual protocol stacks.

VGRS has unparalleled experience in providing registry services using RRP. Transition to a new provisioning protocol introduces several risks to the stability of .org, including data inconsistency, software defects and errors, systems performance, and systems reliability. The experience gained through three years of ongoing operations with RRP, coupled with demonstrated ability to maintain a reliable, scalable registry, will help ensure that the period of initial registry operations will proceed without failure.

The UIA Team is committed to the development of EPP in the IETF. All of the core protocol specifications were written and edited by Scott Hollenbeck, a VGRS Engineering Principal. Mr. Hollenbeck produced the first set of protocol specifications, coordinated the initial effort to publicize the protocol, worked within the IETF to form the provreg working group, and provided ongoing efforts to edit the documents as they've evolved through the IETF's review processes. Mr. Hollenbeck and other team members will remain actively involved in the protocol development and transition efforts to help ensure that the migration from RRP is as smooth and low-cost as possible.

To simplify registrar efforts in the EPP conversion, VGRS will perform EPP migration efforts for .org along with those for .com and .net.


Back to Table of Contents