.org Registry Agreement: Appendix F

12 November 2004

Registry-Registrar Agreement

This Registry-Registrar Agreement (the "Agreement") is between Public Interest Registry, a company organized under the laws of Pennsylvania, with its principal place of business located at 1775 Wiehle Ave, Suite 102A Reston, Virginia 20190 ("Registry Operator"), and [Registrar's name] ______________________, a [jurisdiction and type of organization] ___________________________________________, with its principal place of business located at [Registrar's location] ____________________ _________________________________________ ("Registrar").

WHEREAS, Registry Operator has entered a Registry Agreement with the Internet Corporation for Assigned Names and Numbers to operate a shared registration system, TLD nameservers, and other equipment for the .org top-level domain;

WHEREAS, multiple registrars will provide Internet domain name registration services within the .org top-level domain;

WHEREAS, Registrar wishes to act as a registrar for domain names within the .org top-level domain.

NOW, THEREFORE, for and in consideration of the mutual promises, benefits and covenants contained herein and for other good and valuable consideration, the receipt, adequacy and sufficiency of which are hereby acknowledged, Registry Operator and Registrar, intending to be legally bound, hereby agree as follows:

1. DEFINITIONS

1.1. "APIs" are the application program interfaces by which Registrar may interact, through the EPP or RRP to EPP Proxy, with the Registry System.

1.2. "Confidential Information" means all information and materials, including, without limitation, computer software, data, information, intellectual property, databases, protocols, reference implementation and documentation, financial information, statistics and functional and interface specifications, provided by the Disclosing Party to the Receiving Party under this Agreement and marked or otherwise identified as Confidential, provided that if a communication is oral, the Disclosing Party will notify the Receiving Party in writing, including by email, within 15 days of the disclosure that it is confidential.

1.3. "DNS" means the Internet domain name system.

1.4. "Effective Date" shall be the date on which the Agreement is first executed by both parties.

1.5. Extensible Provisioning Protocol ("EPP") is a highly flexible XML based protocol that is designed to allow multiple registrars access to a registry's SRS.

1.6. "ICANN" means the Internet Corporation for Assigned Names and Numbers.

1.7. "Personal Data" refers to data about any identified or identifiable natural person.

1.8. "Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Registry Operator or an affiliate engaged in providing Registry Services maintains data in a Registry Database, arranges for such maintenance, or derives revenue from such maintenance. A name in a Registry Database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name).

1.9. "Registered Name Holder" means the holder of a Registered Name.

1.10. The "Registrar Tool Kit" comprises the items described in Exhibit A.

1.11. "Registry Agreement" means the Registry Agreement between Registry Operator and ICANN dated 2 December 2002 for the operation of the Registry TLD, as amended from time to time.

1.12. "Registry Database" means a database comprised of data about one or more DNS domain names within the domain of the Registry TLD that is used to generate either DNS resource records that are published authoritatively or responses to domain-name availability lookup requests or Whois queries, for some or all of those names.

1.13. "Registry TLD" means the .org TLD.

1.14. "Registry Services" means services provided as an integral part of the operation of the Registry TLD, including all subdomains in which Registered Names are registered. In determining whether a service is integral to the operation of the Registry TLD, consideration will be given to the extent to which the Registry Operator has been materially advantaged in providing the service by its designation as such under this Agreement. The development of technology, expertise, systems, efficient operations, reputation (including identification as Registry Operator), financial strength, or relationships with registrars and third parties shall not be deemed an advantage arising from the designation. Registry Services include: receipt of data concerning registration of domain names and nameservers from registrars, provision to registrars of status information relating to the Registry TLD, dissemination of TLD zone files, operation of the Registry TLD zone servers, dissemination of contact and other information concerning domain-name and nameserver registrations in the Registry TLD.

1.15. "Registry System" means the system operated by Registry Operator for Registered Names in the Registry TLD.

1.16. "RRP to EPP Proxy" means the registry-registrar interface used by Registrars to access the Registry System during the transition phase as described in Exhibit E.

1.17. "Term" means the term of this Agreement, as set forth in Subsection 9.1.

1.18. "TLD" means a top-level domain of the DNS.

Other terms used in this Agreement as defined terms shall have the meanings ascribed to them in the context in which they are defined.

2. OBLIGATIONS OF REGISTRY OPERATOR

2.1. Access to Registry System. Throughout the Term of this Agreement, Registry Operator shall provide Registrar with access as a registrar to the Registry System that Registry Operator operates according to its arrangements with ICANN. Nothing in this Agreement entitles Registrar to enforce any agreement between Registry Operator and ICANN.

2.2. Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this Agreement, ICANN requirements, and Registry Operator requirements authorized by ICANN, Registry Operator shall maintain the registrations of Registered Names sponsored by Registrar in the Registry System during the term for which Registrar has paid the fees required by Subsection 4.1.

2.3. Provision of Tool Kit; License. No later than three business days after the Effective Date, Registry Operator shall provide to Registrar a copy of the Registrar Tool Kit, which shall provide sufficient technical specifications to permit registrar interface with the Registry System and employ its features that are available to Registrars. Subject to the terms and conditions of this Agreement, Registry Operator hereby grants Registrar and Registrar accepts a non-exclusive, non-transferable, worldwide limited license to use for the Term and purposes of this Agreement, all components owned by or licensed to Registry Operator in and to the RRP to EPP proxy, EPP, APIs, any reference client software and any other intellectual property included in the Registrar Tool Kit, as well as updates and redesigns thereof, to provide domain name registration services in the Registry TLD only and for no other purpose.

2.4. Changes to System. Registry Operator may from time to time make modifications to the RRP to EPP Proxy, EPP, APIs, or other software or materials licensed hereunder that will modify, revise or augment the features of the Registry System. Registry Operator will provide Registrar with at least ninety days notice prior to the implementation of any material changes to the EPP, APIs or software licensed hereunder. However, Registry Operator reserves the right to transition from a RRP to EPP Proxy to a full EPP Registry System with shorter than 90 days notice to the extent that ICANN and Registry Operator agree to that shorter notice.

2.5. Engineering and Customer Service Support. Registry Operator or its subcontractor shall provide Registrar with engineering and customer service support as set forth in Exhibit B.

2.6. Handling of Personal Data. Registry Operator shall notify Registrar of the purposes for which Personal Data submitted to Registry Operator by Registrar is collected, the intended recipients (or categories of recipients) of such Personal Data, and the mechanism for access to and correction of such Personal Data. Registry Operator shall take reasonable steps to protect Personal Data from loss, misuse, unauthorized disclosure, alteration or destruction. Registry Operator shall not use or authorize the use of Personal Data in a way that is incompatible with the notice provided to registrars regarding the purpose and procedures for such use.

Registry Operator may from time to time use the demographic data collected for statistical analysis, provided that this analysis will not disclose individual Personal Data and provided that such use is compatible with the notice provided to registrars.

2.7. Service Level Agreement. Registry Operator shall issue credits to Registrar as described in Exhibit G.

2.8. Registry Services. Registry Operator shall provide Registrar no less than thirty (30) days written notice of any new Registry Service (as defined in this Agreement) that has been approved by ICANN according to the procedures set forth in the Registry Agreement. Such notice shall include provisions of information on pricing, starting date and any additional terms and conditions regarding the new Registry Service. Such notice shall not be a substitute for the notice requirement of Section 2.4 of the Agreement.

2.9. ICANN Requirements. Registry Operator's obligations hereunder are subject to modification at any time as the result of ICANN-mandated requirements and consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by ICANN.

3. OBLIGATIONS OF REGISTRAR

3.1. Accredited Registrar. During the Term of this Agreement, Registrar shall maintain in full force and effect its accreditation by ICANN as a registrar for the Registry TLD.

3.2. Registrar Responsibility for Customer Support. Registrar shall provide (i) support to accept orders for registration, cancellation, deletion or transfer of Registered Names and (ii) customer service (including domain name record support) and billing and technical support to Registered Name Holders.

3.3. Registrar's Registration Agreement. At all times while it is sponsoring the registration of any Registered Name within the Registry System, Registrar shall have in effect an electronic or paper registration agreement with the Registered Name Holder. The initial form of Registrar's registration agreement is attached as Exhibit C (which may contain multiple alternative forms of the registration agreement). Registrar may from time to time amend those forms of registration agreement or add alternative forms of registration agreement, provided a copy of the amended or alternative registration agreement is furnished to the Registry Operator fourteen (14) calendar days in advance of the use of such amended registration agreement. Registrar shall include in its registration agreement those terms required by this Agreement and other terms that are consistent with Registrar's obligations to Registry Operator under this Agreement.

3.4. Indemnification Required of Registered Name Holders. In its registration agreement with each Registered Name Holder, Registrar shall require such Registered Name Holder to indemnify, defend and hold harmless Registry Operator and its subcontractors, shareholders, directors, officers, employees, affiliates and agents of each of them from and against any and all claims, damages, liabilities, costs and expenses, including reasonable legal fees and expenses, arising out of or relating to the Registered Name Holder's domain name registration. The registration agreement shall further require that this indemnification obligation survive the termination or expiration of the registration agreement.

3.5. Compliance with Terms and Conditions. Registrar shall comply with, and shall include in its registration agreement with each Registered Name Holder as appropriate, all of the following:

3.5.1. ICANN standards, policies, procedures, and practices for which Registry Operator has monitoring responsibility in accordance with the Registry Agreement or other arrangement with ICANN; and

3.5.2. operational standards, policies, procedures, and practices for the Registry TLD established from time to time by Registry Operator in a non-arbitrary manner and applicable to all registrars, including affiliates of Registry Operator, and consistent with ICANN's standards, policies, procedures, and practices and Registry Operator's Registry Agreement with ICANN. Among Registry Operator's operational standards, policies, procedures, and practices are those set forth in Exhibit E. Additional or revised Registry Operator operational standards, policies, procedures, and practices for the Registry TLD shall be effective upon thirty days notice by Registry Operator to Registrar. If there is a discrepancy between the terms required by this Agreement and the terms of the Registrar’s Registration Agreement, the terms of this Agreement shall supersede those of the Registrar’s Registration Agreement.

3.6. Data Submission Requirements. As part of its registration and sponsorship of Registered Names in the Registry TLD, Registrar shall submit complete data as required by technical specifications of the Registry System that are made available to Registrar from time to time. Registrar hereby grants Registry Operator a non-exclusive, non-transferable, limited license to such data for propagation of and the provision of authorized access to the TLD zone files and as otherwise required in Registry Operator's operation of the Registry TLD.

3.7. Security. Registrar shall develop and employ in its domain name registration business all necessary technology and restrictions to ensure that its connection to the Registry System is secure and that all data exchanged between Registrar's system and the Registry System shall be protected to avoid unintended disclosure of information. Registrar shall employ the necessary measures to prevent its access to the Registry System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than its own existing customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator, any other registry operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. In addition, Registry Operator may require other reasonable security provisions to ensure that the Registry System is secure.

3.7.1. Registrars shall not provide identical Registrar-generated <authinfo> codes for domain names registered by different registrants with the same Registrar. The Registry Operator in its sole discretion may choose to modify <authinfo> codes for a given domain and shall notify the sponsoring registrar of such modifications via EPP compliant mechanisms (i.e. EPP<poll> or EPP<domain:Info>). Documentation of these mechanisms shall be included in the Registrar toolkit provided by the Registry Operator. The Registrar shall be required to provide the Registered Name Holder with timely access to the authorization code along with the ability to modify the authorization code. Registrar shall respond to any inquiry by a Registered Name Holder regarding access and/or modification within 10 days. Failure of Registrar to timely respond to a Registered Name Holder authorization code inquiry shall constitute an incurable material breach of the Registry-Registrar Agreement.

3.8. Resolution of Technical Problems. Registrar shall employ necessary employees, contractors, or agents with sufficient technical training and experience to respond to and fix all technical problems concerning the use of the RRP, the APIs and the systems of Registry Operator in conjunction with Registrar's systems. In the event of significant degradation of the Registry System or other emergency, Registry Operator may, in its sole discretion, temporarily suspend Registrar's access to the Registry System. Such temporary suspensions shall be applied in a non-arbitrary manner and shall apply fairly to any registrar similarly situated, including affiliates of Registry Operator.

3.9. Time. In the event of any dispute concerning the time of the entry of a domain name registration into the Registry Database, the time shown in the Registry records shall control.

3.10. Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name Holder's existing domain name registration from another registrar by following the policy set forth in Exhibit D. When transferring sponsorship of a Registered Name to or from another registrar, Registrar shall comply with the requirements of Exhibit D.

3.11. Registration Term. Registrar shall immediately register with the Registry Operator the full length of the registration term of each Registered Name as provided under Registrar's Registration Agreement with the Registered Name Holder for the Registered Name. Neither Registrar nor any affiliated company shall accept a multi-year registration or renewal of a Registered Name but then fail to register the Registered Name for the full term for which the Registered Name Holder has paid.

3.12. Restrictions on Registered Names. In addition to complying with ICANN standards, policies, procedures, and practices limiting domain names that may be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain names that may be registered.

4. FEES

4.1. Amount of Registry Operator Fees. Registrar agrees to pay Registry Operator the fees set forth in Exhibit F for initial and renewal registrations and other services provided by Registry Operator to Registrar (collectively, "Fees"). Registry Operator reserves the right to revise the Fees prospectively upon thirty days notice to Registrar, provided that such adjustments are consistent with the Registry Agreement.

4.2. Payment of Registry Operator Fees. A Registrar's credit limit is based on the payment security comprised of an irrevocable Letter of Credit, Cash Deposit or combination thereof maintained with Registry Operator. As domain names are registered, the Registrar's account is reduced. A monthly invoice will be mailed from the Registry Operator to the Registrar for domain names processed during the preceding month. The Registrar must pay this invoice upon receipt in order to ensure timely processing of future domain name registrations.

If the Registrar should fail to pay the invoice within terms or if the payment security should be depleted, registration of domain names for the Registrar will be suspended and new registrations will not be accepted until the payment security is replenished.

4.3. Non-Payment of Fees. Registrar's timely payment of Fees is a material condition of Registry Operator's obligations under this Agreement. Registry Operator may do any or all of the following: (i) stop accepting new initial or renewal registrations from Registrar; (ii) delete the domain names associated with invoices not paid in full from the Registry database; (iii) give written notice of termination of this Agreement pursuant to Subsection 9.2.1; and (iv) pursue any other remedy under this Agreement.

4.4. Parity of ICANN Support Fees. Registry Operator may pay Variable Registry-Level Fees to ICANN under Subsection 3.14.2 of its Registry Agreement with ICANN. In consideration of Registry-Operator's payment of these fees, Registrar provides the following assurance of parity of support of ICANN among TLDs: For any period in which (i) Registry Operator pays ICANN Variable Registry-Level Fees for the Registry TLD; (ii) Registrar is not required to pay ICANN an on-going component of registrar accreditation fees for accreditation as a registrar in the Registry TLD; (iii) the Registry Operator for the .com and .net TLDs is not obligated by its Registry Agreement with ICANN to pay ICANN Variable Registry-Level Fees; and (iv) Registrar is accredited by ICANN as a registrar in the .com and .net TLDs, Registrar hereby gives its express approval of an on-going component of its Registrar accreditation fees for .com and .net TLDs that is equivalent, on a per-name basis, to the Variable Registry-Level Fee paid by Registry Operator to ICANN with respect to the Registry TLD.

4.5 Refund of Unused Fees. Should this Agreement be terminated, the unused payment security will be refunded 60 days after the termination of the agreement.

5. CONFIDENTIALITY AND INTELLECTUAL PROPERTY

5.1. Use of Confidential Information. During the Term of this Agreement, each party (the "Disclosing Party") may disclose its Confidential Information to the other party (the "Receiving Party"). Each party's use and disclosure of the Confidential Information of the other party shall be subject to the following terms and conditions:

5.1.1. The Receiving Party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information of the Disclosing Party, including implementing reasonable physical security measures and operating procedures.

5.1.2. The Receiving Party agrees that it will use any Confidential Information of the Disclosing Party solely for the purpose of exercising its right or performing its obligations under this Agreement and for no other purposes whatsoever.

5.1.3. The Receiving Party shall make no disclosures whatsoever of any Confidential Information of the Disclosing Party to others; provided, however, that if the Receiving Party is a corporation, partnership, or similar entity, disclosure is permitted to the Receiving Party's officers, employees, contractors and agents who have a demonstrable need to know such Confidential Information, provided the Receiving Party shall advise such personnel of the confidential nature of the Confidential Information and of the procedures required to maintain the confidentiality thereof, and shall require them to acknowledge in writing that they have read, understand, and agree to be individually bound by the confidentiality terms of this Agreement.

5.1.4. The Receiving Party shall not modify or remove any confidentiality legends and/or copyright notices appearing on any Confidential Information of the Disclosing Party.

5.1.5. The Receiving Party agrees not to prepare any derivative works based on the Confidential Information.

5.1.6. Notwithstanding the foregoing, this Subsection 5.1 imposes no obligation upon the parties with respect to information that (i) is disclosed in the absence of a confidentiality agreement and such disclosure was agreed to by the Disclosing Party in writing prior to such disclosure; or (ii) is or has entered the public domain through no fault of the Receiving Party; or (iii) is known by the Receiving Party prior to the time of disclosure; or (iv) is independently developed by the Receiving Party without use of the Confidential Information; or (v) is made generally available by the Disclosing Party without restriction on disclosure.

5.1.7. The Receiving Party's duties under this Subsection 5.1 shall expire two (2) years after the expiration or termination of this Agreement or earlier, upon written agreement of the parties.

5.2. Intellectual Property.

5.2.1. Subject to the licenses granted hereunder, each party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets, proprietary processes and all other forms of intellectual property.

5.2.2. Without limiting the generality of the foregoing, no commercial use rights or any licenses under any patent, patent application, copyright, trademark, know-how, trade secret, or any other intellectual proprietary rights are granted by the Disclosing Party to the Receiving Party by this Agreement, or by any disclosure of any Confidential Information to the Receiving Party under this Agreement.

6. INDEMNITIES AND LIMITATION OF LIABILITY

6.1. Indemnification. Registrar, at its own expense and within thirty days after presentation of a demand by Registry Operator under this Section, will indemnify, defend and hold harmless Registry Operator and its subcontractors, and the employees, members, shareholders, directors, officers, representatives, agents and affiliates of each of them, against any claim, suit, action, or other proceeding brought against Registry Operator or its subcontractors, or any affiliate of Registry Operator or its subcontractors, based on or arising from any claim or alleged claim: (i) relating to any product or service of Registrar; (ii) relating to any agreement, including Registrar's dispute policy, with any Registered Name Holder or Registrar; or (iii) relating to Registrar's domain name registration business, including, but not limited to, Registrar's advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service. Registry Operator shall provide Registrar with prompt notice of any such claim, and upon Registrar's written request, Registry Operator will provide to Registrar all available information and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses Registry Operator for Registry Operator's actual and reasonable costs incurred in connection with providing such information and assistance. Registrar will not enter into any settlement or compromise of any such indemnifiable claim without Registry Operator's prior written consent, which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not limited to, reasonable attorneys' fees and costs awarded against or otherwise incurred by Registry Operator or the other indemnified person in connection with or arising from any such indemnifiable claim, suit, action or proceeding.

6.2. Representation and Warranty. Registrar represents and warrants that: (i) it is a corporation duly incorporated, validly existing and in good standing under the law of the state of [________] (ii) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (iii) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, and (iv) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement.

6.3. Limitation of Liability. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY, OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS OR BUSINESS INTERRUPTION, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. IN NO EVENT SHALL THE MAXIMUM AGGREGATE LIABILITY OF REGISTRY OPERATOR AND ITS SUBCONTRACTORS EXCEED THE LESSER OF (i) THE TOTAL AMOUNT PAID TO REGISTRY OPERATOR UNDER THE TERMS OF THIS AGREEMENT FOR THE IMMEDIATELY PRECEEDING 12 MONTH PERIOD, OR (ii) $100,000 USD.

6.4. Disclaimer of Warranties. THE REGISTRAR TOOL KIT AND ALL OTHER ITEMS PROVIDED BY REGISTRY OPERATOR OR ITS SUBCONTRACTORS HEREUNDER ARE PROVIDED "AS-IS" AND WITHOUT ANY WARRANTY OF ANY KIND. REGISTRY OPERATOR EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. REGISTRY OPERATOR DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE REGISTRAR TOOL KIT WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF THE REGISTRAR TOOL KIT WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE REGISTRAR TOOL KIT WILL BE CORRECTED. FURTHERMORE, REGISTRY OPERATOR DOES NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE REGISTRAR TOOL KIT OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE REGISTRAR TOOL KIT PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.

7. INSURANCE.

7.1. Insurance Requirements. Registrar shall acquire, prior to the Effective Date, at least US $1,000,000 in comprehensive general liability insurance from a reputable insurance provider with an A.M. Best rating of "A" or better naming Registry Operator as an additional insured and shall maintain insurance meeting these requirements throughout the Term of this Agreement. Registrar shall provide a copy of the insurance policy to Registry Operator upon Registry Operator's reasonable request.

8. DISPUTE RESOLUTION

8.1. Dispute Resolution. Disputes arising under or in connection with this Agreement, including requests for specific performance, shall be resolved through binding arbitration conducted as provided in this Section pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce ("ICC"). The arbitration shall be conducted in the English language and shall occur in the State of Virginia, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. Any litigation brought to enforce an arbitration award shall be brought in the state or federal courts in the State of Virginia, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of a party during the pendency of an arbitration, each party shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or a court located in the state or federal courts in the State of Virginia, USA, which shall not be a waiver of this arbitration agreement.

9. TERM AND TERMINATION

9.1. Term of the Agreement; Revisions. The Term of this Agreement shall commence on the Effective Date and, unless earlier terminated in accordance with the provisions of this Agreement, shall expire on the last day of the calendar month which is sixty months after the Effective Date. In the event that revisions to Registry Operator's approved form of Registry-Registrar Agreement are approved or adopted by ICANN, Registrar will either execute an amendment substituting the revised agreement in place of this Agreement or, at its option exercised within fifteen days after receiving notice of such amendment, terminate this Agreement immediately by giving written notice to Registry Operator. In the event that Registry Operator does not receive such executed amendment or notice of termination from Registrar within such fifteen day period, Registrar shall be deemed to have terminated this Agreement effective immediately.

9.2. Termination. This Agreement may be terminated as follows:

9.2.1. Termination For Cause. In the event that either party materially breaches any of its obligations under this Agreement and such breach is not substantially cured within thirty calendar days after written notice thereof is given by the other party, then the non-breaching party may, by giving written notice thereof to the other party, terminate this Agreement as of the date specified in such notice of termination.

9.2.2. Termination at Option of Registrar. Registrar may terminate this Agreement at any time by giving Registry Operator thirty days notice of termination.

9.2.3. Termination Upon Loss of Registrar's Accreditation. This Agreement shall terminate in the event Registrar's accreditation by ICANN is terminated or expires without renewal.

9.2.4. Termination in the Event of Termination of Registry Agreement. This Agreement shall terminate in the event that the Registry Agreement is terminated or expires without entry of a subsequent Registry Agreement with ICANN and this Agreement is not assigned under Subsection 10.1.1.

9.2.5. Termination in the Event of Insolvency or Bankruptcy. Either party may terminate this Agreement if the other party is adjudged insolvent or bankrupt, or if proceedings are instituted by or against a party seeking relief, reorganization or arrangement under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the appointment of a receiver, liquidator or trustee of a party's property or assets or the liquidation, dissolution or winding up of a party's business.

9.3. Effect of Termination. Upon the expiration or termination of this Agreement for any reason:

9.3.1. Registry Operator will complete the registration of all domain names processed by Registrar prior to the effective date of such expiration or termination, provided that Registrar's payments to Registry Operator for Fees are current and timely.

9.3.2. Registrar shall immediately transfer its sponsorship of Registered Names to another ICANN-accredited registrar in compliance with any procedures established or approved by ICANN.

9.3.3. All Confidential Information of the Disclosing Party in the possession of the Receiving Party shall be immediately returned to the Disclosing Party.

9.3.4. In the event of termination in accordance with the provisions of Subsections 9.2.1, 9.2.2 or 9.2.3, Registry Operator reserves the right to immediately contact any and all Registered Name Holders to facilitate the orderly and stable transition of Registered Name Holders to other ICANN-accredited registrars.

9.3.5. All fees owing to Registry Operator shall become immediately due and payable.

9.4. Survival. In the event of termination of this Agreement, the following shall survive: (i) Subsections 2.6, 3.6, 5.1, 5.2, 6.1, 6.3, 6.4, 8.1, 9.4, 10.2, 10.3, 10.4, 10.6, 10.7 and 10.8 and (ii) the Registered Name Holder's indemnification obligation under Subsection 3.4. Neither party shall be liable to the other for damages of any sort resulting solely from terminating this Agreement in accordance with its terms.

10. MISCELLANEOUS

10.1. Assignments.

10.1.1. Assignment to Successor Registry Operator. In the event the Registry Agreement is terminated or expires without execution by Registry Operator and ICANN of a subsequent registry agreement, Registry Operator's rights under this Agreement may be assigned to a company with a subsequent registry agreement covering the Registry TLD upon ICANN's giving Registrar written notice within sixty days of the termination or expiration, provided that the subsequent registry operator assumes the duties of Registry Operator under this Agreement.

10.1.2. Assignment in Connection with Assignment of Agreement with ICANN. In the event that the Registry Agreement is validly assigned, Registry Operator's rights under this Agreement shall be automatically assigned to the assignee of the Registry Agreement, provided that the assignee assumes the duties of Registry Operator under this Agreement. In the event that Registrar's accreditation agreement with ICANN for the Registry TLD is validly assigned, Registrar's rights under this Agreement shall be automatically assigned to the assignee of the accreditation agreement, provided that the subsequent registrar assumes the duties of Registrar under this Agreement.

10.1.3. Other Assignments. Except as otherwise expressly provided in this Agreement, the provisions of this Agreement shall inure to the benefit of and be binding upon, the successors and permitted assigns of the parties. Neither party shall assign or transfer its rights or obligations under this Agreement without the prior written consent of the other party, which shall not be unreasonably withheld.

10.2. Notices. Any notice or other communication required or permitted to be delivered to any party under this Agreement shall be in writing and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business hours) to the address or telecopier number set forth beneath the name of such party below, unless such party has given a notice of a change of address or individual representation in writing:

If to Registrar:

with copy to:

If to Registry Operator:

Public Interest Registry
1775 Wiehle Ave, Suite 102A
Reston, Virginia 20190
Attention: President
Phone: +1-703-464-7005
Facsimile: +1-703-464-7006

with a copy to:
Public Interest Registry
1775 Wiehle Ave, Suite 102A
Reston, Virginia 20190
Attention: General Counsel
Phone: +1-703-464-7005
Facsimile: +1-703-464-7006

10.3. Third-Party Beneficiaries. The parties expressly agree that ICANN is an intended third-party beneficiary of this Agreement. Otherwise, this Agreement shall not be construed to create any obligation by either party to any non-party to this Agreement, including any holder of a Registered Name. Registrar expressly acknowledges that, notwithstanding anything in this Agreement to the contrary, it is not an intended third-party beneficiary of the Registry Agreement.

10.4. Relationship of the Parties. Nothing in this Agreement shall be construed as creating an employer-employee or agency relationship, a partnership or a joint venture between the parties.

10.5. Force Majeure. Neither party shall be liable to the other for any loss or damage resulting from any cause beyond its reasonable control (a "Force Majeure Event") including, but not limited to, insurrection or civil disorder, war or military operations, national or local emergency, acts or omissions of government or other competent authority, compliance with any statutory obligation or executive order, industrial disputes of any kind (whether or not involving either party's employees), fire, lightning, explosion, flood, subsidence, weather of exceptional severity, and acts or omissions of persons for whom neither party is responsible. Upon occurrence of a Force Majeure Event and to the extent such occurrence interferes with either party's performance of this Agreement, such party shall be excused from performance of its obligations (other than payment obligations) during the first six months of such interference, provided that such party uses best efforts to avoid or remove such causes of nonperformance as soon as possible.

10.6. Amendments. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties.

10.7. Waivers. No failure on the part of either party to exercise any power, right, privilege or remedy under this Agreement, and no delay on the part of either party in exercising any power, right, privilege or remedy under this Agreement, shall operate as a waiver of such power, right, privilege or remedy; and no single or partial exercise or waiver of any such power, right, privilege or remedy shall preclude any other or further exercise thereof or of any other power, right, privilege or remedy. Neither party shall be deemed to have waived any claim arising out of this Agreement, or any power, right, privilege or remedy under this Agreement, unless the waiver of such claim, power, right, privilege or remedy is expressly set forth in a written instrument duly executed and delivered on behalf of such party; and any such waiver shall not be applicable or have any effect except in the specific instance in which it is given.

10.8. Entire Agreement. This Agreement (including its exhibits, which form a part of it) constitutes the entire agreement between the parties concerning the subject matter of this Agreement and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth herein.

10.9. Counterparts. All executed copies of this Agreement are duplicate originals, equally admissible as evidence. This Agreement may be executed in counterparts, and such counterparts taken together shall be deemed the Agreement. A facsimile copy of a signature of a party hereto shall have the same effect and validity as an original signature.

IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the Effective Date set forth below hereof.

Public Interest Registry

By:
Name:
Title:

[Registrar]

By:
Name:
Title:

Effective Date: ________________________

Exhibit A
REGISTRAR TOOL KIT

The Registrar Tool Kit will consist of a working Java API and samples and C samples for Registrars to communicate with the Registry System, both during the transition phase described in Exhibit E through the RRP to EPP Proxy and during and after the transition phase through normal operations of the EPP protocol. The samples will illustrate how XML requests (Registration Events) can be assembled and forwarded to the Registry Operator for processing. The software will provide the Registrar with the basis for a reference implementation that conforms to the Registry-Registrar Protocol. The software component of the Registrar Tool Kit will be based on static XML requests.

The documentation will explain to the Registrar the details of the protocol specification. It will describe the commands that need to be sent to the Registry System in order to support domain registration events, as well as the possible responses that may be returned by the Registry Operator. The precise nature of the sequencing of commands, as well as the payload that must be assembled and transmitted to the Registry Operator, will be defined for each possible registration event.

The documentation will also describe the software that implements the EPP Registry-Registrar protocol as well as RRP to EPP Proxy that will be utilized during the transition phase. This will consist of a description of the software package hierarchy, and an explanation of the defined objects and methods (including calling parameter lists, and expected response behavior).

The Registrar Tool Kit will be licensed under the GNU Lesser General Public License and this Agreement.

Exhibit B
ENGINEERING AND CUSTOMER SERVICE SUPPORT

Registrar will be provided with customer support services by the Registry Operator of three types:

• Front line customer support
• Administrative/billing/financial support
• Technical support

Front Line Customer Support. The front line support is the first point of contact for Registrar. Front line support will be available on a 24/7 basis. This operation will be able to answer general registrar questions. When the answer is not available or Registrar is not satisfied with the answer, a service support case is opened and a support ticket is issued. These support tickets are escalated to either the technical support team or the administrative/financial/billing support team depending on the nature of the problem.

Methods of contact that will be supported by customer support will include: telephone, fax, postal mail and e-mail.

Administrative/Financial/Billing Support. The administrative/financial/billing support team will deal with Registrar's business, account management, financial and billing issues. Examples that fall into these categories include:

• Registrar account balance inquiries
• Registrar low-balance warning notifications
• Crediting a Registrar's account after payment
• Legal issues related to the registry-registrar agreement
• Administrative issues for the acceptance of new registrars

The support team will have guidelines to ensure a conduit exists for escalation to higher levels of registry management with respect to unresolved administrative/billing/financial issues.

Technical Support. The technical support team is responsible for dealing with Registrar's technical issues. Registry Operator shall provide a package of support services through the Technical Support Group (TSG). Overall, the TSG shall attempt to provide around the clock, real time professional support to all registrars that have entered into Registry-Registrar Agreements with Registry Operator, ranging from basic inquiries to high-level operations critical technical support.

Registry Operator's operation staff shall be available 24/7, with required members of the department on call. Escalation procedures shall be in place, ensuring that management is notified of service outages in a timely manner.

Access to Registry Data. The TSG shall have access to Registry System data to support Registrar, to the extent that current operating status can be determined, response to specific Registrar queries about Registrar specific data or specific transactions can be provided. Registry Operator employees shall be required to properly identify the Registrar before providing any Registrar critical data, and shall be prohibited from providing information about other Registrar operations.

Notifications. The TSG shall be responsible for notifying Registrar of upcoming maintenance and outages. At a minimum, all planned outages and maintenance shall be announced at least 7 days prior to the scheduled date. Further, the TSG shall be required to provide immediate notice of unplanned or unscheduled outages and maintenance.

Customer Escalation Process. The TSG will operate with a customer escalation process. Normally, support calls or other forms of communication shall start with the lowest level of support, and be escalated should the first level of support be insufficient. In cases where higher levels of support are immediately apparent (all levels of support staff will be trained in identifying these) the escalation chain may be jumped. Also, should the time limit expire with no notice, the support level may be escalated. The escalation levels and response requirements are as follows:

Level 1 - Technical based questions, usually unique to the Registrar that may require support from a Registry System operator or engineer. Requests for information or technical support shall be provided within an hour unless is it deemed to be a Level 2 incident.

Level 2 - Registry System outages involving non-critical operations to the registry affecting one or more registrars only, but not the entire system. Response reports shall be provided every 30 minutes, by no less than a qualified Registry System engineer.

Level 3 - Catastrophic outages, or disaster recovery involving critical operations to the Registry System overall. Response reports shall be provided every 15 minutes, by no less than a senior Registry System engineer.

Security of Customer Support Service. Registrar must supply a list of specific individuals (5 to 10 people) that are authorized to contact the Registry Operator. Each individual will also be assigned a pass phrase. Any phone requests made by Registrar to Registry Operator's customer service will have to come from someone on the authorized list, and require the pass phrase to be supplied. In the event that an attempt is made to contact the Registry Operator's customer service on behalf of Registrar, but appropriate authentication is not provided, Registry Operator will make contact with Registrar to inform it of a breach of security protocol.

Customer Satisfaction Surveys. In order to fairly judge the quality of its customer services, Registry Operator may hire an outside party to perform customer satisfaction surveys on a regular basis. The result of these surveys will be used to identify and correct problems with the customer service process. Registry Operator will also use these results to measure improvements in customer satisfaction.

Subcontract. All references to Registry Operator in this Exhibit B shall be deemed to include Registry Operator's subcontractors, to the extent appointed by Registry Operator.

Exhibit C
REGISTRAR'S REGISTRATION AGREEMENT
[To be supplied by Registrar]

Exhibit D
POLICY ON TRANSFER OF SPONSORSHIP OF
REGISTRATIONS BETWEEN REGISTRARS

A. Holder-Authorized Transfers.

1. Registrar Requirements.

Registered Name Holders must be able to transfer their domain name registrations between Registrars provided that the Gaining Registrar's transfer process meets the minimum standards of this policy and that such transfer is not prohibited by ICANN or Registry policies. Inter-Registrar domain name transfer processes must be clear and concise in order to avoid confusion. Further, Registrars should make reasonable efforts to inform Registered Name Holders of, and provide access to, the published documentation of the specific transfer process employed by the Registrars.

1.1 Transfer Authorities

The Administrative Contact and the Registered Name Holder, as listed in the Losing Registrar's or applicable Registry's (where available) publicly accessible WHOIS service are the only parties that have the authority to approve or deny a transfer request to the Gaining Registrar. In the event of a dispute, the Registered Name Holder's authority supersedes that of the Administrative Contact.

Registrars may use Whois data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request; or from another data source as determined by a consensus policy.

2. Gaining Registrar Requirements

For each instance where a Registered Name Holder requests to transfer a domain name registration to a different Registrar, the Gaining Registrar shall:

2.1 Obtain express authorization from either the Registered Name Holder or the Administrative Contact (hereafter, "Transfer Contact"). Hence, a transfer may only proceed if confirmation of the transfer is received by the Gaining Registrar from the Transfer Contact.

2.1.1 The authorization must be made via a valid Standardized Form of Authorization (FOA). There are two different FOA's available at the ICANN website. See The FOA labeled "Initial Authorization for Registrar Transfer" must be used by the Gaining Registrar to request an authorization for a registrar transfer from the Transfer Contact. The FOA labeled "Confirmation of Registrar Transfer Request" may be used by the Registrar of Record to request confirmation of the transfer from the Transfer Contact.

The FOA shall be communicated in English, and any dispute arising out of a transfer request shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, Registrars choosing to exercise such option are responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA.

2.1.2 In the event that the Gaining Registrar relies on a physical process to obtain this authorization, a paper copy of the FOA will suffice insofar as it has been signed by the Transfer Contact and further that it is accompanied by a physical copy of the Registrar of Record's Whois output for the domain name in question.

2.1.2.1 If the Gaining Registrar relies on a physical authorization process, then the Gaining Registrar assumes the burden of obtaining reliable evidence of the identity of the Transfer Contact and maintaining appropriate records proving that such evidence was obtained. Further the Gaining Registrar also assumes the burden for ensuring that the entity making the request is indeed authorized to do so. The acceptable forms of physical identity are:

• Notarized statement
• Valid Drivers license
• Passport
• Article of Incorporation
• Military ID
• State/Government issued ID
• Birth Certificate

2.1.3 In the event that the Gaining Registrar relies on an electronic process to obtain this authorization the acceptable forms of identity would include:

• Electronic signature in conformance with national legislation, in the location of the Gaining Registrar (if such legislation exists).
• Consent from an individual or entity that has an email address matching the Transfer Contact email address.

The Registrar of Record may not deny a transfer request solely because it believes that the Gaining Registrar has not received the confirmation set forth above.

A transfer must not be allowed to proceed if no confirmation is received by the Gaining Registrar. The presumption in all cases will be that the Gaining Registrar has received and authenticated the transfer request made by a Transfer Contact.

2.2 Request, by the transmission of a "transfer" command as specified in the Registrar Tool Kit, that the Registry Operator database be changed to reflect the new Registrar.

2.2.1 Transmission of a "transfer" command constitutes a representation on the part of the Gaining Registrar that the requisite authorization has been obtained from the Transfer Contact listed in the authoritative Whois database.

2.2.2 The Gaining Registrar is responsible for validating the Registered Name Holder requests to transfer domain names between Registrars. However, this does not preclude the Registrar of Record from exercising its option to independently confirm the Registered Name Holder's intent to transfer its domain name to the Gaining Registrar in accordance with Section 3 of this policy.

3. Obligations of the Registrar of Record

A Registrar of Record can choose independently to confirm the intent of the Registered Name Holder when a notice of a pending transfer is received from the Registry. The Registrar of Record must do so in a manner consistent with the standards set forth in this agreement pertaining to Gaining Registrars. In order to ensure that the form of the request employed by the Registrar of Record is substantially administrative and informative in nature and clearly provided to the Transfer Contact for the purpose of verifying the intent of the Transfer Contact, the Registrar of Record must use the FOA.

The FOA shall be communicated in English, and any dispute arising out of a transfer request, shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, the Registrar choosing to exercise such option is responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA. Further, such non-English communications must follow the processes and procedures set forth in this policy. This includes but is not limited to the requirement that no Registrar shall add any additional information to the FOA used to obtain the consent of the Transfer Contact in the case of a transfer request.

This requirement does not preclude the Registrar of Record from marketing to its existing customers through separate communications.

The FOA should be sent by the Registrar of Record to the Transfer Contact as soon as operationally possible, but must be sent not later than twenty-four (24) hours after receiving the transfer request from the Registry Operator.

Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer.

In the event that a Transfer Contact listed in the Whois has not confirmed their request to transfer with the Registrar of Record and the Registrar of Record has not explicitly denied the transfer request, the default action will be that the Registrar of Record must allow the transfer to proceed.

Upon denying a transfer request for any of the following reasons, the Registrar of Record must provide the Registered Name Holder and the potential Gaining Registrar with the reason for denial. The Registrar of Record may deny a transfer request only in the following specific instances:

1. Evidence of fraud
2. UDRP action
3. Court order by a court of competent jurisdiction
4. Reasonable dispute over the identity of the Registered Name Holder or Administrative Contact
5. No payment for previous registration period (including credit card charge-backs) if the domain name is past its expiration date or for previous or current registration periods if the domain name has not yet expired. In all such cases, however, the domain name must be put into "Registrar Hold" status by the Registrar of Record prior to the denial of transfer.
6. Express written objection to the transfer from the Transfer Contact. (e.g. - email, fax, paper document or other processes by which the Transfer Contact has expressly and voluntarily objected through opt-in means)
7. A domain name was already in .lock status. provided that the Registrar provides a readily accessible and reasonable means for the Registered Name Holder to remove the lock status.
8. A domain name is in the first 60 days of an initial registration period.
9. A domain name is within 60 days (or a lesser period to be determined) after being transferred (apart from being transferred back to the original Registrar in cases where both Registrars so agree and/or where a decision in the dispute resolution process so directs).

Instances when the requested change of Registrar may not be denied include, but are not limited to:

• Nonpayment for a pending or future registration period
• No response from the Registered Name Holder or Administrative Contact.
• Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.
• Domain name registration period time constraints, other than during the first 60 days of initial registration or during the first 60 days after a registrar transfer.
• General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration.

The Registrar of Record has other mechanisms available to collect payment from the Registered Name Holder that are independent from the Transfer process. Hence, in the event of a dispute over payment, the Registrar of Record must not employ transfer processes as a mechanism to secure payment for services from a Registered Name Holder. Exceptions to this requirement are as follows:

• In the case of non-payment for previous registration period(s) if the transfer is requested after the expiration date, or
• In the case of non-payment of the current registration period, if transfer is requested before the expiration date.

4. Registrar Coordination

Each Registrar is responsible for keeping copies of documentation, including the FOA and the Transfer Contacts response thereto, that may be required for filing and supporting a dispute under the dispute resolution policy. Gaining Registrars must maintain copies of the FOA as received from the Transfer Contact as per the standard document retention policies of the contracts. Copies of the reliable evidence of identity must be kept with the FOA.

Both the Gaining Registrar and the Registrar of Record must provide the evidence relied on for the transfer during and after the applicable inter-registrar domain name transaction(s). Such information must be provided when requested by, and only by, the other Registrar that is party to the transfer transaction. Additionally, ICANN, the Registry Operator, a court or authority with jurisdiction over the matter or a third party dispute resolution panel may also require such information within five (5) days of the request.

The Gaining Registrar must retain, and produce pursuant to a request by a Losing Registrar, a written or electronic copy of the FOA. In instances where the Registrar of Record has requested copies of the FOA, the Gaining Registrar must fulfill the Registrar of Records request (including providing the attendant supporting documentation) within five (5) calendar days. Failure to provide this documentation within the time period specified is grounds for reversal by the Registry Operator or the Dispute Resolution Panel in the event that a transfer complaint is filed in accordance with the requirements of this policy.

If either a Registrar of Record or a Gaining Registrar does not believe that a transfer request was handled in accordance with the provisions of this policy, then the Registrar may initiate a dispute resolution procedure as set forth in Section C of this policy.

For purposes of facilitating transfer requests, Registrars should provide and maintain a unique and private email address for use only by other Registrars and the Registry:

• This email address is for issue related to transfer requests and the procedures set forth in this policy only.
• The email address should be managed to ensure messages are received by someone who can respond to the transfer issue.
• Messages received at such email address must be responded to within a commercial reasonable timeframe not to exceed seven (7) calendar days.

5. EPP - based Registry Requirements for Registrars

In EPP-based gTLD Registries, Registrars must follow the requirements set forth below.

Registrars must provide the Registered Name Holder with the unique "AuthInfo" code within five (5) calendar days of the Registered Name Holder's initial request if the Registrar does not provide facilities for the Registered Name Holder to generate and manage their own unique "AuthInfo" code.

Registrars may not employ any mechanism for complying with a Registered Name Holder's request to obtain the applicable "AuthInfo Code" that is more restrictive than the mechanisms used for changing any aspect of the Registered Name Holder's contact or name server information.

The Registrar of Record must not refuse to release an "AuthInfo Code" to the Registered Name Holder solely because there is a dispute between the Registered Name Holder and the Registrar over payment.

Registrar-generated "AuthInfo" codes must be unique on a per-domain basis.

The "Auth-Info" codes must be used solely to identify a Registered Name Holder, whereas the FOA's still need to be used for authorization or confirmation of a transfer request, as described in Section 2 and Section 4 of this policy.

6. Registry Requirements

Upon receipt of the "transfer" command from the Gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. In the case of those Registries that use electronic mail notifications, the response notification may be sent to the unique email address established by each Registrar for the purpose of facilitating transfers.

The Registry Operator shall complete the requested transfer unless, within five (5) calendar days, Registry Operator receives a NACK protocol command from the Registrar of Record.

When the Registry's database has been updated to reflect the change to the Gaining Registrar, Registry Operator will transmit an electronic notification to both Registrars. The notification may be sent to the unique email address established by each Registrar for the purpose of facilitating transfers or such other email address agreed to by the parties.

The Registry Operator shall undo a transfer if, after a transfer has occurred, the Registry Operator receives one of the notices as set forth below. In such case, the transfer will be reversed and the domain name reset to its original state. The Registry Operator must undo the transfer within five (5) calendar days of receipt of the notice except in the case of a Registry dispute decision, in which case the Registry Operator must undo the transfer within fourteen calendar days unless a court action is filed. The notice required shall be one of the following:

• Agreement of the Registrar of Record and the Gaining Registrar sent by email, letter or fax that the transfer was made by mistake or was otherwise not in accordance with the procedures set forth in this policy;
• The final determination of a dispute resolution body having jurisdiction over the transfer; or
• Order of a court having jurisdiction over the transfer.

7. Records of Registration

Each Registrar shall require its customer, the Registered Name Holder, to maintain its own records appropriate to document and prove the initial domain name registration date.

8. Effect on Term of Registration

The completion by Registry Operator of a holder-authorized transfer under this Part A shall result in a one-year extension of the existing registration, provided that in no event shall the total unexpired term of a registration exceed ten (10) years.

B. ICANN-Approved Transfers

Transfer of the sponsorship of all the registrations sponsored by one Registrar as the result of (i) acquisition of that Registrar or its assets by another Registrar, or (ii) lack of accreditation of that Registrar or lack of its authorization with the Registry Operator, may be made according to the following procedure:

1. The gaining Registrar must be accredited by ICANN for the Registry TLD and must have in effect a Registry-Registrar Agreement with Registry Operator for the Registry TLD.
2. ICANN must certify in writing to Registry Operator that the transfer would promote the community interest, such as the interest in stability that may be threatened by the actual or imminent business failure of a Registrar.

Upon satisfaction of these two conditions, Registry Operator will make the necessary one-time changes in the Registry database for no charge, for transfers involving 50,000 name registrations or fewer. If the transfer involves registrations of more than 50,000 names, Registry Operator will charge the gaining Registrar a one-time flat fee of US$ 50,000.

C. Transfer Dispute Resolution Policy

Procedures for handling disputes concerning inter-registrar transfers are set forth in the Transfer Dispute Resolution Policy (available at: http://www.icann.org/transfers/dispute-policy-12jul04.htm). Procedures in this policy must be followed by the applicable Registry Operators and ICANN accredited Registrars.

Exhibit E
REGISTRY OPERATOR'S OPERATIONAL STANDARDS,
POLICIES, PROCEDURES, AND PRACTICES

I. Cancellation of Registered Names. Registry Operator may transfer or cancel any Registered Name (i) for violations of this Agreement and its Exhibits or (ii) to correct mistakes made by Registry Operator or any Registrar in connection with a domain name registration.

II. Additional Requirements for Registration Agreement. In addition to the provisions of Subsection 3.4, in its registration agreement with each Registered Name Holder, Registrar shall require such Registered Name Holder to:

(i) consent to the use, copying, distribution, publication, modification and other processing of Registered Name Holder's Personal Data by Registry Operator and its designees and agents in a manner consistent with the purposes specified pursuant to Subsection 2.6;

(ii) submit to proceedings commenced under ICANN's Uniform Domain Name Dispute Resolution Policy ("UDRP"); and

(iii) immediately correct and update the registration information for the Registered Name during the registration term for the Registered Name.

III. Additional Security. Each session wherein Registrar accesses the Registry System shall be authenticated and encrypted using two-way secure socket layer ("SSL") protocol. At a minimum, Registrar shall authenticate every client connection with the Registry System using both an X.509 server certificate issued by a commercial certification authority identified by the Registry Operator and its Registrar password. Registrar shall disclose only its Registrar password to its employees with a need to know. Registrar agrees to notify Registry Operator within four hours of learning that its Registrar password has been compromised in any way or if its server certificate has been revoked by the issuing certification authority or compromised in any way.

IV. Updates to Registration Information. Registrar shall submit any corrections or updates from a Registered Name Holder relating to the registration information for a Registered Name to Registry Operator in accordance with such timeline and specifications as Registry Operator may develop.

V. Policies Concerning Transition of the .org Top-Level Domain to Operation by Registry Operator.

The technical transition from the VeriSign Registry ("Verisign") to Public Interest Registry ("PIR") will involve a multi-step procedure, outlined in detail below.

1. Technical Transition – Verisign Registry to PIR Registry

1.1: Conversion Data Specification

The data required for the transition will be detailed to VeriSign, and will include, but not be limited to, thin-registry WHOIS information currently held by by VeriSign, the gTLD zone file for .ORG, and registrar information relating to the operation of the registry (registrar ID mappings, for example). All data currently maintained by registrars will not need to be loaded into the system. Domain names and associated child entities will be converted real-time, as registrars move to the EPP-based system.
The registry data should be formatted in a common symbol delimited text file, with the first row containing appropriate column headers. The gTLD zone file can be sent in the current text format. If these formats are determined to be insufficient, an alternative format shall be negotiated between PIR and VeriSign, as long as this negotiation does not prolong the process of receiving the data. This data will be formally requested no more than three days following the signing of the .ORG Registry Agreement.

1.2: Form Registrar Transition Focus Group (RTFG)

PIR will immediately begin selecting and contacting registrars to formulate the Registrar Transition Focus Group. The mission of this group is: 1) to provide input from a registrar's perspective on the transition, 2) to provide a level of testing to ensure that the software works as documented, and 3) to ensure client software can be successfully transitioned in a timely basis.

1.3: Receive full set of test data from VeriSign

No later than 10 days after the request in 1.1 of this Appendix J has been issued, PIR expects to receive, in the common symbol-delimited form decided upon, the complete set of data to be used, solely for the purposes of testing the transition. PIR shall request Verisign to estimate a time for the retrieval and transmission of the data set, so that appropriate time can be allocated during the cutover process.

1.4: Conversion to test environment

Upon arrival of the test data, PIR will begin testing the conversion process, and load this data into a test environment to be accessed by both PIR developers as well as the RTFG. The conversion data will be segmented into two files: one considered a "full" data dump, and the second considered an "incremental" data dump.
The conversion process will involve first loading the "full" data dump, and subsequently processing the incremental dumps. Collectively, this is referred to as the "conversion process." This step is expected to be completed no later than 21 days after the data has been received.

1.5: Confirm readiness of VeriSign DNS API

PIR intends to utilize VeriSign's name servers during the transition period. This is contingent upon VeriSign having a mechanism on its side of the transfer. PIR expects to have access to a test API system no later than 7 days after the contract is signed. An API test area will also be expected from Verisign, which will generate a zone file based on the data sent in through the API. (Alternatively, PIR will be able to provide zone files based on a specification agreed with VeriSign.)

1.6: Begin internal testing and provide Test Arena ("Sandbox")

Once the data has been successfully loaded into the test arena, PIR and the RTFG will be allowed to conduct tests on the data to verify registry operations. PIR's initial testing will be conducted using a standard test suite that has already been built by PIR's back-end services provider for the purposes of verifying registry operations. The initial test suite will include at least the following areas:

1. RRP transaction processing

2. Zone File propagation and accuracy (including utilization of the VeriSign API and test area for zone file transfer - as soon as it is available)

3. Proper WHOIS data propagation and accuracy - for both RRP and EPP domains

4. PIR shall provide a test arena ("Sandbox") for all registrars to begin testing their client code. Registrars shall be provided separate methods of authentication in order to access this Sandbox.

This test phase will begin as soon as the data has been loaded into the test arena.

1.7: Implement changes from Focus Group and Internal Testing

During the testing phase, problems that are found within the registry system will be documented, ticketed into the bug tracking system, and resolved in a timely manner. As problems are resolved, fixes will be introduced back into the system using the same Quality Assurance procedure that PIR's back-end services provider uses in its current production environment. While many problems will be resolved during the initial testing phase, there may be issues that require an extensive change.

1.8: Reload VeriSign test data and re-run test suite

Once it is believed that all fixes are in place from the previous steps, PIR will re-run the data conversion process, and the test suite. The RTFG will be encouraged to conduct testing on their end to verify the results. It is expected that this will take no more than 7 days.

1.9: Begin Data Migration to production-ready system

Once system operations have been verified, VeriSign will need to provide another full set of data, identical in format and nature as the data provided in 1.1 of this Appendix J. This data will be loaded into the production-ready system using the conversion program, and data will be checked for accuracy. No transform commands will be allowed on this data. This full data dump is expected to occur at least 30 days before the cutover date. An incremental dump will then be expected at regular intervals before the cutover, and the incremental conversions will occur. All data will be checked for accuracy.

1.10: Shut down VeriSign RRP system

At the time of the cutover, VeriSign will shut down their RRP system. This assures that PIR has a complete set of data when PIR's registry goes live. VeriSign's WHOIS service, as well as the gTLD name servers, will remain operational throughout the cutover.

1.11: Receive last incremental dump from VeriSign

Immediately after the RRP shutdown, VeriSign will be expected to run the last incremental dump of the data, generate a zone file, and send this to PIR as quickly as possible, using the same methodology as described in previous steps. Utilizing incremental dumps will help minimize the downtime required in this process.

1.12: Run last incremental conversion into production system

Upon receiving the data, PIR will immediately load the data using the incremental conversion process. The data will then be verified for accuracy and completeness, using the same mechanisms that were utilized in the testing environments.

1.13: Bring up VeriSign nameserver API

VeriSign will need to back up the current zone file, and bring up the mechanism to allow PIR's zone file to be transferred to the VeriSign name servers. Once this mechanism is running, PIR will initiate a push to the name servers, and verify that all operations are running correctly.

1.14: Bring up RRP/EPP proxy system

Once all data and the name server functionality have been verified, PIR will bring up the RPP/EPP proxy system. All operations will be carefully monitored throughout this process, to ensure that all registry operations are functioning correctly.

1.15. WHOIS Services

WHOIS services will be provided in the thin model for all .ORG names operating under RRP, for which the central .ORG WHOIS server will provide referrals to the authoritative WHOIS servers.

2. Technical Transition – Post cut-over

2.1: Registrars begin EPP migration

Registrars will begin the migration from RRP to EPP in early 2003. Each registrar will be given a commercially feasible timeframe to cutover to the EPP protocol. The EPP migration process will commence in early 2003, and shall conclude no later than December 31, 2003.

2.2: WHOIS Services (thin to thick registry)

As part of the EPP migration, Registrars shall be required to provide full contact information required for thick registry WHOIS services. Thick registry WHOIS services will be provided for each .ORG name that has been migrated to EPP.

2.3: Test UltraDNS API and name server functionality

Once the cutover is completed, PIR will begin testing the transfer procedure to UltraDNS. The testing will be conducted in a similar manner as was done with the VeriSign API.

2.4: Run Parallel name servers

For a period of 30 days, PIR will send zone file data to both VeriSign and UltraDNS name servers. The UltraDNS servers will be checked for accuracy and completeness.

2.5: ICANN to switch name server delegation

Once the accuracy of the UltraDNS zone file propagation has been successfully completed, PIR will request ICANN to switch the name servers from VeriSign to UltraDNS.

2.6: VeriSign to remove PIR connectivity to their name servers

As part of the contingency outlined below, it is expected that VeriSign will keep the connectivity to the nameservers alive until 30 days after the delegation change. This step would complete the transition.

2.7: RRP and EPP co-existence

The registry will be pre-loaded with all relevant RRP data from VeriSign. If a registrar connects to the registry using RRP, it will be able to manipulate the data in the same manner as it does today through VeriSign. If the registrar connects via EPP, it will need to modify the domain name to include/update all required fields for that entity and its children (contact ROIDS, etc.). This modification step will be included in the OT&E process.

2.8: Registrar data migration to thick model

PIR will encourage registrars to migrate their data from the thin to thick registry model. This encouragement will include, but is not limited to, a weekly report showing all domains still under the thin model, full technical support and OT&E testing facilities, and notifications by PIR to migrate the data in a timely fashion.
PIR will discontinue operation of the RRP/EPP proxy software on January 1, 2004. As a result, Registrars are required to complete migration to the EPP system prior to December 31, 2003, or risk being disconnected and unable to access the Registry system.

Once all registrars have made the transition to EPP, the RRP-to-EPP proxy will be shut down, and all registry operations from that point forward will be transacted using EPP.

3. Technical Transition – Interruption of Registry Functions

PIR's transition plan aims to minimize any interruption to critical services during and after the cutover of the Registry. Because the cutover only involves the shutdown of the RRP service from VeriSign, PIR expects no interruption of service for the key end-user components of name resolution and WHOIS services.
By using the incremental dump methodology described above, PIR will minimize the amount of down time that will occur during the cutover process. This will only impact registrars' ability to transform existing registry-related information, such as name servers delegated to a particular domain, as the registry data will not be accessible during this time. All data maintained by the registrar, in their own WHOIS databases, will not be affected. The cutover process is expected to last for at least 48 hours. Once the cutover has been completed, no further interruption of service is expected.

4. Technical Transition – Contingency Plans

PIR shall create contingency plans in the event that any part of the proposed transition does not proceed as planned. Listed below are the minimal steps that shall be undertaken by PIR to ensure that the transition of the registry results in minimal disruption of service to registrars, and no disruption of service to existing .ORG registrants.
Each step in the transition is outlined below, with each step's risk assessment and contingency plan is detailed. This is for illustrative purposes only, and the Registry Operator reserves the right to make modifications to details of the Transition Plan, and the Contingency Plan(s) in order to ensure that the stability and security of the .ORG registry is not compromised.

4.1: Conversion Data Specification Contingency

In the event that VeriSign cannot supply the data in the format suggested in 1.1 of this Appendix J, PIR will work with VeriSign to establish a format that will be mutually acceptable. Both companies have the necessary technical knowledge to agree to a format in a short time frame.

4.2: Registrar Transition Focus Group (RTFG) Contingency

PIR's back-end registry services operator, has prior experience in establishing registrar groups similar to the RTFG during its LandRush 2 process. PIR will seek out alternate registrars or similarly technically competent organizations to participate in the RTFG.

4.3: Full set of test data from VeriSign Contingency

PIR will depend on VeriSign to be able to deliver data in a timely fashion to Registry Operator for the purposes of load testing the conversion process. If, however, VeriSign cannot deliver this data in time for the initial testing to commence, Registry Operator will generate a set of test data. This data is anticipated to be a representative model, but presents risk as it may only be an approximation of expected data to be later delivered from Versign.

4.4: Conversion to test environment Contingency

If problems are found within the test data, then the Registry Operator's development team will work with VeriSign to correct the problem and have the data set regenerated. The purpose of this step is to check for errors in both the data set and the conversion code, so some errors and their appropriate fixes are expected. The largest risk in this step is the indication of an unexpected amount of errors in the conversion code, which could potentially increase the time needed for this step.

4.5: Internal testing Contingency

Internal testing will begin once the data set has been loaded successfully. The RTFG testing will be available after the preliminary internal testing has concluded.

4.6: Reload VeriSign test data and re-run test suite – Contingency

The procedures for loading all data will have been fully tested at this point. If, after fixing any problems incurred in the previous steps, the data fails to load, the conversion process will be altered to correct the problem. The time allotment for this step allows for this iteration to occur.

4.7: Data Migration to production-ready system Contingency

At this point in the transition, the data load will have been tested numerous times. The risk factors here include a problem with VeriSign providing the production data, or an unforeseen error in the conversion code - both of which are unlikely at this point. If however, such an error occurs, PIR will work expeditiously with VeriSign to resolve this issue as quickly as possible. This step can occur anytime within the month prior to the cutover. While some time has been allocated for this step in the event of a problem, in the event of an unavoidable problem beyond the control of the Registry Operator, the Registry Operator will take necessary emergency steps to mitigate the risk of destabilizing the .ORG registry.

4.8: Shut down VeriSign RRP system - Contingency

The principal potential risk here is having other registry services affected by the closure of the RRP system at VeriSign. It is assumed that VeriSign has run the production system many times in this scenario. In the extremely unlikely event that either DNS or WHOIS services are affected adversely by the RRP shutdown, the cutover will be delayed until the problem can be resolved. VeriSign will be asked to provide, in writing and in advance of the cutover, a statement verifying that the RRP system can indeed be shutdown in this manner. In the event of a catastrophic failure at this point, the conversion will be aborted, and VerSign can re-open their RRP system.

4.9: Receive last incremental dump from VeriSign - Contingency

The major risk in this step is timing. It is currently not known how long it will take VeriSign to retrieve and send the incremental data set to PIR. The RRP downtime will be extended at this point if this step should take longer than anticipated. In the event of a catastrophic failure at this point, the conversion will be aborted, and VerSign can re-open their RRP system.

4.10: Run last incremental conversion into production system - Contingency

At this point in the transition, it will be known how long it takes to run an incremental conversion. – As many as five incremental conversions will have been performed to this point. In the event of a catastrophic failure at this point, the conversion will be aborted, and Versign can re-open their RRP system.

4.11: Bring up VeriSign nameserver API - Contingency

If an unforeseen issue should arise, and the registry is unable to communicate to VeriSign's name servers, attempts will be made to correct the issue. Should this prove to be an overwhelming task, the conversion will be aborted, and VeriSign can re-open their RRP system.

4.12: Bring up RRP/EPP proxy system - Contingency

If the registry system fails to come up, or unable to perform all registry services as expected, attempts will be made to correct the issue. If, however, it is determined that a problem exists that cannot be resolved in a timely manner, the system will be brought down, and VeriSign can re-open their RRP system.

4.13: Registrar EPP Migration - Contingency

PIR will handle each registrar's EPP Migration process. The RRP to EPP proxy allows registrars to continue to perform domain functions while preparing their systems for the change. In the event that a registrar has problems moving to the EPP system, they can continue to operate using RRP until the proper corrections have been made. Registry Operator shall provide necessary technical assistance (including debugging assistance) to help ensure that Registrars complete the migration to EPP successfully.

4.14: UltraDNS API and name server functionality - Contingency

The UltraDNS API is well documented, and the changes required to switch to the new name servers should be minimal. This coupled with the extended time frame allowed makes the risk factor low.

In the event that a serious problem should occur, PIR shall utilize VeriSign's name servers for the duration of the 12 months as provided for by the current contractual requirements from VeriSign.

4.15: VeriSign to remove PIR connectivity to their name servers - Contingency

Once the registry is running on the new name servers, PIR will no longer attempt any connectivity whatsoever to the VeriSign name servers. VeriSign can bring down this service on its own time-frame.

4.16: PostgreSQL database is orphaned

Because of the open source nature of PostgreSQL, the software code base does not suffer the same inherent business issues that one would see in a commercial package. Specifically, there is no underlying concern regarding the company's financial health; the code being bought out and obfuscated by a competitor; corporate espionage; etc. These kinds of risks do not affect open source products such as PostgreSQL.

Although "orphaning" by a corporate parent does not apply, there are two different scenarios where support could falter for the use of PostgreSQL. The first is a radical shift in database theory, and the related implementations, and the second is lethargy within the development community.

The first issue deals with the adoption of new database theories and technologies. In this regard, PostgreSQL excels. PostgreSQL did not originally have SQL built in. However, as the SQL standards progressed, it was incorporated into the system, and is now one of the most fully compliant SQL implementations. The adoption of new database technologies has occurred many times within the lifecycles of PostgreSQL. As new ideas develop within the database community, PostgreSQL has developed a reputation for implementing these new ideas in a timely fashion.

The second issue deals with the notion that programmers will migrate to a totally new project, and work on PostgreSQL will slow to a minimum. Given PostgreSQL's history with adaptation to standards and new technologies, as well as a sixteen-year development history, it is difficult to envision that this would occur.
Open-source data conversion utilities for PostgreSQL exist, whose explicit purpose is to facilitate the migration of data to and from PostgreSQL. As a direct result, PIR's ability to convert the data contained in its database is made significantly easier, should the need occur.

Assuming, however, that an unforeseen issue would occur which would cause PostgreSQL to no longer be maintained in an appropriate fashion, PIR would begin the migration to another database subsystem. PostgreSQL, by virtue of its conformance to industry standards, would ease the burden of migration. Overall, the degree of difficulty in migrating the data to another database system is finite and measurable. Data migration can be performed with the skill sets that Registry Operator's back-end services provider has already built in-house, as well from the PostgreSQL community.

Each RDBMS contains significant architectural differences, which must be accommodated in any data migration. Since PostgreSQL is accessible in an open and cross-platform manner via both ODBC and JDBC, a consistent application programming interface (API) is available that works with different databases through the use of database-specific drivers.

A consistent API results in function calls to perform important database actions such as initiating a connection, executing a command, and retrieving results that are identical regardless of whether the program is talking to PostgreSQL or another ODBC/JDBC compliant database. Additionally, a standardized call-level interface and standard escape sequences allow the data migration developer to specify SQL functions that perform common tasks but are executed differently in the two database systems.

The data migration process (as differentiated from a registry transition process, which includes data migration) needs to take into account several important considerations. The data migration process must identify differences and determine methods of resolving such differences and create a uniform mapping for critical tasks and functions, such as:

• Physical and Logical Storage Structures
• Data access methods across RAID or non-RAID devices
• Access to transaction logs and automated recovery methods
• Ability to perform various backup methods, including full and differential backups, as well as snapshots
• File encryption methods
• Network security access and specialized database functions
• Groups, roles and permissions, and migration of roles between databases
• Common definition and/or mapping of database objects
• Object names and identifier differences
• Qualifying table names
• Syntax for table creation, index and storage parameters
• SQL syntax mapping for important functions, such as views and queries
• Use of Unicode data
• Enforcing Data Integrity and Business Rules, including constraints
• Identifying differences and mapping functionality for transactions, locking and concurrency
• Methods of handling deadlocks
• Conversion of values to different data types
• Conversion of user-defined functions, stored procedures and special calls
• Raising program errors, common error processing methods and debug systems

Should PIR need to migrate data from its current database to a new database, the planned migration strategy would adhere to the following guidelines:

14.16.1 Determine a suitable successor database. This would involve testing various database systems within our environment, to see how each performs under the registry's normal and peak load conditions.

14.16.2 Once the successor database has been selected, the software will be procured (if not open source), installed, and appropriately configured into our test environments (see ISOC .ORG proposal, C 17-13.2-4).

14.16.3 A new set of database servers would be procured. These new servers would need to be configured and installed.

14.16.4 A data export / import procedure will be built in parallel with the development efforts in Step 4.

14.16.5 All pertinent API DB calls would be modified within the registry software (if necessary).

14.16.6 Queries would be re-analyzed to ensure that they are still optimized using the new system.

14.16.7 Once all software has been unit tested, the entire system will undergo an exhaustive test phase.

14.16.8 Any revisions that are derived from the test suites will be worked out.

14.16.9 The database would be loaded onto the procured servers, and a database export / import would be performed. No shutdown would need to occur for this step. The data would be exhaustively checked for any errors, and additional export / imports run to correct any mistakes.

14.16.10 The registry will be shutdown, the new database systems installed, an incremental export / import run, the data examined, and brought back up.

5. Technical Transition – Cooperation from VeriSign Registry

As the current operator of the .ORG registry, VeriSign must play an integral part of the transition process. To successfully transition the registry, PIR requires at least the following information and services from VeriSign:

5.1 An initial production data dump.

This includes the ability to provide both a full data set (including the corresponding zone file), and incremental sets that contain only changes from the original full data set. This will be needed for both the testing phase, as well as the production cutover. VeriSign should also provide approximate timeframes when these data sets will be available, in order to accurately gauge the cutover time.

5.2 Authorization to use the VeriSign nameservers for a period of up to 12 months.

PIR's transition plan calls for use of VeriSign's nameservers for the first 180 days after the cutover, but may be required for the entire 12 months as part of the contingency plan.

5.3 Written confirmation from VeriSign that VeriSign Registry's Whois and DNS services will not be interrupted when the VeriSign RRP system is stopped during the cutover.

5.4 VeriSign will need to provide and coordinate appropriate Application Programming Interfaces (APIs) into their name servers within 7 days of the signing of the .ORG contract.

5.5 PIR also requests an environment setup at VeriSign to test the DNS API mechanism within 10 days of the signing of the .ORG contract.

5.6 Extensive, timely coordination between PIR and VeriSign shall be required throughout the transition, with complete coverage during the cutover process. VeriSign shall take commercially reasonable steps to ensure that such coordination is provided in a timely manner.

5.7 In order to provide continuity of service to registrars and registrants, PIR will need VeriSign's cooperation (and relevant data) regarding the other areas of .ORG registry operation that VeriSign is currently responsible for. These areas include (but are not limited to) customer service, policy, technical, legal, and arbitration information. Examples include open .ORG trouble tickets, information regarding ongoing .ORG domain disputes, information regarding services the VeriSign registry currently offers to .ORG registrants and registrars, etc.

6. Operational Test & Evaluation (OT & E)

Before ICANN-Accredited Registrars will be allowed to join the live registration environment, they must first pass Operational Test and Evaluation ("OT&E") certification.

The OT&E process has two main objectives:

1. Verifying the correct operation of an ICANN-Accredited Registrar's client system, and the ICANN-Accredited Registrar's capability to operate the interface with the Registry; and

2. Establishing the contractual and business relationship between the ICANN-Accredited Registrar and the Registry, in accordance with the Registry-Registrar Agreement.

The OT&E certification process will be available to all ICANN-Accredited Registrars starting from the date described in Section 7 below.

6.1: Phase 1 - OT&E for cutover to new Registry Operator

All ICANN-Accredited Registrars who wish to perform transactions in the .ORG domain will have to make necessary technical and other modifications to their systems and processes to ensure that they connect to the PIR registry systems, and that these systems are able to execute RRP-based domain name transaction commands without any loss of functionality.

All ICANN-Accredited Registrars will be required to pass certain tests to be eligible to go live prior to the January 1, 2003 cutover of the registry. All tests performed during OT&E certification must be completed without errors. Registry Operator will provide the certification results in a timely manner and provide feedback for those ICANN-Accredited Registrars that failed to successfully complete the tests. ICANN-Accredited Registrars may correct their systems and re-schedule for certification. ICANN-Accredited Registrars will not be limited in the number of attempts at OT&E certification. Upon successful OT&E certification, the ICANN-Accredited Registrar becomes eligible for operation in the live registration environment. For specific technical details see Section 7 of Appendix C to the Registry Agreement.

6.2: Phase 2 - OT&E for RRP (thin) to EPP (thick) conversion

Since PIR will operate a central, authoritative registry database that operates on the EPP protocol, all ICANN-Accredited Registrars who wish to perform transactions in the .ORG domain will have to make necessary technical and other modifications to their systems and processes to ensure that they connect to the PIR registry systems, and that these systems are able to perform required transactions in the EPP protocol with Registry Systems. In addition, since PIR will operate the EPP registry under the "thick" provision (centralized information repository), all registrars will have to make the necessary technical and other modifications to their systems and processes to ensure that they can successfully and completely transfer necessary contact information from their systems to PIR.

All ICANN-Accredited Registrars will be required to pass certain tests to be eligible to go live pri