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 proposed Equivalent Access Certification and Registry Code of Conduct documents are included below. The proposed Equal Access and Nondiscriminatory Practice agreement is essentially similar to the one at http://www.icann.org/tlds/agreements/pro/registry-agmt-apph-12mar01.htm

The .Org Foundation equivalent access certification

The .Org Foundation in its capacity as the Registry Operator, and on behalf of its contractors such as the Registry Service Provider makes the following certifications:

1. The Registry Service Provider contractor, initially selected as eNom, Inc., will not be an Accredited Registrar in .org
2. All ICANN-Accredited Registrars connect to the RRP/EPP (Registry-Registrar Protocol) via the Internet by equivalent connection(s) and by utilizing the equivalent maximum number of IP addresses and SSL certificate authentications. Notwithstanding the foregoing, any ICANN Accredited Registrar's access may be proportionately increased based on a need demonstrated by the past level of queries by such registrar, provided that such level of access be available to other similarly situated ICANN Accredited Registrars.
3. The Registry Operator will make commercially reasonable efforts to make any software required for domain name registration such as a toolkit, and any updates to that toolkit, available to all ICANN-Accredited Registrars at the same time.
4. All ICANN-Accredited Registrars have equivalent level of access to Registry customer support personnel via telephone, e-mail or the Registry website
5. All ICANN-Accredited Registrars have equivalent level of access to the Registry resources, as made available from time to time, to resolve Registry/Registrar or Registrar/Registrar disputes and technical and/or administrative customer service issues.
6. All ICANN-Accredited Registrars have equivalent level of access to Registry Data to reconcile their registration activities from registry Web and ftp servers. Each ICANN-Accredited Registrar's data will be treated as confidential, per the Registry Code of Conduct.
7. All ICANN-Accredited Registrars are enabled to perform basic automated registrar account management functions using an equivalent Registrar toolkit or other means made available to all Accredited Registrars by the Registry Service Provider. All account information is treated as confidential, per the Registry Code of Conduct.
8. The Registry-Registrar Protocol does not include any algorithms or protocols that differentiate among ICANN-Accredited Registrars with respect to functionality, including database access, system priorities, access to re-registering deleted names, and overall performance.
9. All Registry Operator officers, directors, shareholders, employees, agents, consultants, and contractors are directed not to give preferential treatment to any individual ICANN-Accredited Registrar.
10. The Registry Operator does not provide preferential pricing structures, promotions or other economic terms with respect to Registry Services to any individual ICANN-Accredited Registrar that are not available to all ICANN-Accredited Registrars.
11. Registry Operator has complied with the terms of the Registry Operator Code of Conduct and the Equal Access and Nondiscrimination Practice Plan.

Registry Code of Conduct

The .org Foundation (Foundation) will at all times operate as a trusted neutral third-party provider of Registry Services. The .org Foundation recognizes that domain names are the means by which businesses, consumers, and individuals gain access to, navigate, and reap the benefits of the global Internet. These benefits cannot be fully realized, however, unless DNS resources are administered in a fair, efficient, and neutral manner that makes them available to all parties desiring to provide DNS services. To ensure the provision of neutral Registry Services, The .org Foundation will comply with the following Code of Conduct.

1. The Foundation will not directly or indirectly, show any preference or provide any special consideration to any ICANN-Accredited Registrar in the .org Registry versus another ICANN-Accredited Registrar in the .org Registry, as those terms are defined by ICANN.
2. The Foundation will not maintain any ownership interest in any ICANN accredited Registrar or Registry, and visa-versa.
3. All ICANN-Accredited Registrations in the .org registry shall have equivalent access to those Registry Services operated by the Foundation.
4. The Foundation and its shareholders and subcontractors shall not in any way attempt to warehouse or register domain names in their own right, except for names designated for operational purposes in compliance with Subsections 3.6.1 and 3.6.2 of the Registry Agreement. In its Monthly Report to ICANN, the Foundation shall include a list of all names designated for operational purposes.
5. Any shareholder, subsidiary, affiliate, or other related entity of the Foundation that also operates as a provider of registrar services shall maintain separate books of account with respect to its registrar operations.
6. Neither the Foundation, nor its owners, subsidiaries, affiliates, or other related entities shall have access to user data or proprietary information of an ICANN-Accredited Registrar, except as necessary for registry management and operations.
7. The Foundation will ensure that no user data or proprietary information from any ICANN-Accredited Registrar is disclosed to its affiliates, subsidiaries, or other related entities, except as necessary for registry management and operations.
8. Confidential information about the Foundation business services will not be shared with employees of any DNS registry operator or ICANN-Accredited Registrars, except as necessary for registry management and operations.
9. The Foundation will conduct internal neutrality reviews on a regular basis. In addition, the Foundation and ICANN may mutually agree on an independent party that ICANN may hire, at ICANN's expense, to conduct a neutrality review of the Foundation, ensuring that the Foundation and its owners comply with all the provisions of this Registry Operator Code of Conduct. The neutrality review may be conducted as often as once per year. The Foundation will provide the analyst with reasonable access to information and records appropriate to complete the review. The results of the review will be provided to ICANN and shall be deemed to be confidential and proprietary information of the Foundation and its owners.

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.

The development of the registry system will be designed from the ground up to support the EPP protocol. RRP will simply be a layer around it that can easily be removed once the registrar community has made the transition to EPP. eNom will be running the RRP and EPP systems in parallel on both the OT&E environment as well as production.

The EPP protocol is designed to associate registrant and other contact information with a domain name. The RRP protocol does not require, nor does it maintain, any information related to the registrant or other contacts.

eNom's strategy is to assign a default contact for all required contact fields while the RRP protocol is still in use for the org TLD. The information for this contact will simply state that contact information has not been provided and is just to provide referential integrity during the transition. This information will not be displayed in the WhoIs output or any other publicly accessible means while the RRP protocol is still being accepted. Registrars will be required to update these contact fields (described below) within a specified timeline.

A registrar will be required to complete a certification test to be allowed access to the EPP system. The certification procedure will be documented and available to registrars on the registry web site.

Registrars will be able to develop and test their clients in the OT&E environment. Once the registrar feels they are ready, they can schedule a time to perform the certification test.

The transactions of the certification test will be logged and evaluated after completion of the test. Customer service will then correspond with the registrar notifying them of their performance and information on any issues that may have been found during the testing.

Once a deadline has been set to transition to the EPP protocol, eNom will notify all registrars 120 days prior of eNom's intent to transition completely to EPP.

1. eNom will allow registrars 60 days to finish development on their EPP clients and perform the certification tests. During this period registrars that have passed the certification test may then begin to register domain names and update their contacts. Once contact information has been updated, the information will begin getting displayed in the Whois service.
2. After the 60 day period has expired, the RRP protocol portion of the registry software will be removed and the host and ports previously used for RRP will no longer accept connections.
3. Registrars will have an additional 60 days from this time to continue acquiring and updating contact information for their domains. Registrars will also be notified that any missing contact information may result in the domain being placed on hold, removing its zone information from the DNS servers until the contact information is updated.
4. After the final 60 days has expired any domains that do not have appropriate contact information will be placed on hold until the contact information is updated.
5. eNom will have its portion implemented within the 135 day window. However, extended support for legacy RRP will be given as described above.

C23 and C24. Intentionally omitted.