Proposed Unsponsored TLD Agreement: Appendix F (.info) Posted: 26 April 2001

This Registry-Registrar Agreement (the "Agreement") is between Afilias Limited, a company organized under the laws of Ireland, with its principal place of business located at 1 Stokes Place, Dublin 2, Ireland ("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 .info top-level domain;

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

WHEREAS, Registrar wishes to act as a registrar for domain names within the .info 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. The "APIs" are the application program interfaces by which Registrar may interact, through the RRP, 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. The "Effective Date" shall be the date on which the Agreement is first executed by both parties.

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

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

1.7. "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.8. "Registered Name Holder" means the holder of a Registered Name.

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

1.10. "Registry Agreement" means the Registry Agreement between Registry Operator and ICANN dated [date of Registry Agreement] for the operation of the Registry TLD.

1.11. "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.12. "Registry TLD" means the .info TLD.

1.13. "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. These 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.14. The "Registry System" means the system operated by Registry Operator for Registered Names in the Registry TLD.

1.15. "RRP" means the registry-registrar protocol used by the Registry System.

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

1.17. A "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, 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, 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 RRP, APIs or software licensed hereunder.

2.5. Engineering and Customer Service Support. Registry Operator 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.

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

2.8. 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 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 holder of the name. 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 directors, officers, employees and agents 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.

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.

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. 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 Registry Operator's Registry Agreement with ICANN.

4.2. Payment of Registry Operator Fees. In advance of incurring Fees, Registrar shall establish a letter of credit, deposit account, or other credit facility accepted by Registry Operator, which acceptance will not be unreasonably withheld. Registry Operator will invoice Registrar monthly in arrears for the Fees incurred by Registrar in the month. All Fees are due immediately upon receipt of Registry Operator's invoice pursuant to the letter of credit, deposit account, or other credit facility.

4.3. Non-Payment of Fees. Registrar's timely payment of Fees is a material condition of Registry Operator's obligations under this Agreement. In the event that Registrar fails to pay its Fees within five days of the date when due, 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, .net, and .org 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, .net, and .org TLDs, Registrar hereby gives its express approval of an on-going component of its Registrar accreditation fees for .com, .net, and .org 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.

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 employees, directors, officers, representatives, agents and affiliates, against any claim, suit, action, or other proceeding brought against Registry Operator or any affiliate of Registry Operator 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 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 OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

6.4. Disclaimer of Warranties. THE REGISTRAR TOOL KIT IS 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 Delaware, 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 Delaware, 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 Delaware, 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 Registry Operator's Registry Agreement with ICANN 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. 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 Operator's Registry Agreement is terminated or expires without entry 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 Registry Operator's Registry Agreement with ICANN for the Registry TLD 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 in writing:

If to Registrar:

with copy to:

If to Registry Operator:

Afilias Limited
c/o Kent Jordan
Corporate Domains, Inc.
2711 Centerville Rd., Suite 400
Wilmington, Delaware 19808 USA
phone: +1 302 636-5400
fax: +1 302 636-5454

with a copy to:

Rita A. Rodin
Skadden, Arps, Slate, Meagher & Flom, LLP
Four Times Square
New York, New York 10036 USA
phone: +1 212 735-3000
fax: +1 212 735-2000

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.

IN WITNESS WHEREOF, the parties hereto have executed this Agreement as of the date set forth in the first paragraph hereof.

Afilias Limited By: Name: Title:

[Registrar] By: Name: Title:

The Registrar Tool Kit will consist of a working Java API and samples and C samples that can be used to implement the EPP protocol that is used to communicate between the Registry System and Registrar. 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. 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.

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.

A. Holder-Authorized Transfers.

Registrar Requirements.

The registration agreement between each Registrar and its Registered Name Holder shall include a provision explaining that a Registered Name Holder will be prohibited from changing its Registrar during the first 60 days after initial registration of the domain name with the Registrar. Beginning on the 61st day after the initial registration with the Registrar, the procedures for change in sponsoring registrar set forth in this policy shall apply. Enforcement shall be the responsibility of the Registrar sponsoring the domain name registration.

For each instance where a Registered Name Holder wants to change its Registrar for an existing domain name (i.e., a domain name that appears in a particular top-level domain zone file), the gaining Registrar shall:

1) Obtain express authorization from an individual who has the apparent authority to legally bind the Registered Name Holder (as reflected in the database of the losing Registrar).

a) The form of the authorization is at the discretion of each gaining Registrar.

b) The gaining Registrar shall retain a record of reliable evidence of the authorization.

2) In those instances when the Registrar of record is being changed simultaneously with a transfer of a domain name from one party to another, the gaining Registrar shall also obtain appropriate authorization for the transfer. Such authorization shall include, but not be limited to, one of the following:

a) A bilateral agreement between the parties.

b) The final determination of a binding dispute resolution body.

c) A court order.

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

a) Transmission of a "transfer" command constitutes a representation on the part of the gaining Registrar that:

(1) the requisite authorization has been obtained from the Registered Name Holder listed in the database of the losing Registrar, and

(2) the losing Registrar will be provided with a copy of the authorization if and when requested.

In those instances when the Registrar of record denies the requested change of Registrar, the Registrar of record shall notify the prospective gaining Registrar that the request was denied and the reason for the denial.

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

1) Situations described in the Domain Name Dispute Resolution Policy.

2) A pending bankruptcy of the Registered Name Holder.

3) Dispute over the identity of the Registered Name Holder.

4) Request to transfer sponsorship occurs within the first 60 days after the initial registration with the Registrar.

In all cases, the losing Registrar shall respond to the e-mail notice regarding the "transfer" request within five (5) days. Failure to respond will result in a default "approval" of the "transfer."

Registry Requirements.

Upon receipt of the "transfer" command from the gaining Registrar, Registry Operator will transmit an e-mail notification to both Registrars.

Registry Operator shall complete the "transfer" if either:

1) the losing Registrar expressly "approves" the request, or

2) Registry Operator does not receive a response from the losing Registrar within five (5) days.

When the Registry's database has been updated to reflect the change to the gaining Registrar, Registry Operator will transmit an email notification to both Registrars.

Records of Registration.

Each Registered Name Holder shall maintain its own records appropriate to document and prove the initial domain name registration date, regardless of the number of Registrars with which the Registered Name Holder enters into a contract for registration services.

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 acquisition of that Registrar or its assets by another Registrar may be made according to the following procedure:

(a) 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.

(b) 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.

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 the Sunrise Dispute Resolution Policy ("SDRP");

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

(iv) acknowledge that Registry Operator will have no liability of any kind for any loss or liability resulting from the proceedings and processes relating to the Sunrise Period or the Land Rush Period, including, without limitation: (a) the ability or inability of a registrant to obtain a Registered Name during these periods, and (b) the results of any dispute over a Sunrise Registration.

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. Start-Up Plan.

1. Logical Queue System

Submission of registrations:

On the respective dates on which Registry Operator begins processing Registered Name registrations in the Sunrise and Land Rush Periods (each a "Start Date"), Registry Operator will enable Registrar to submit their registrations into individual logical queue databases. The order of the Registered Name requests in Registrar's queue will then be randomized at the Registry System.

Processing of queued registrations:

Registry Operator will process Registered Name requests using a round robin mechanism such that no more than one request per round will be processed for Registrar, whether such request is accepted or not, so long as more than any other registrar that is a party to a Registry-Registrar Agreement with Registry Operator (an "Authorized Registrar") has requests remaining in its logical queue. A Registered Name request will be considered successful if: (i) the domain name is available and (ii) Registrar has in place a mechanism to pay the registration fees for such registration, as described in the Agreement. This round robin process will continue until all Registered Name requests in each individual logical queue have been processed.

No real time registrations will be processed during the round robin rotation, so, while these initial logical queues are processed, Registrar may submit new Registered Name registrations to a new database logical queues. Once the initial logical queues have been processed, the Registry System will begin processing the next logical queues and the process will repeat according to the schedule described in the next section.

Projected schedules for rounds of registrations:

Registry Operator expects there to be 5 rotations of its round robin registration system for the Sunrise and Land Rush Periods, as follows (the number of days specified for processing and monitoring are maximum periods):

First Rotation: The submission period for the first rotation is scheduled to last 7 days. At the end of 7 days, the individual logical queues will be randomized as described above. After the queues are randomized, the Registry System will begin processing Registered Name registrations. This processing is estimated to last 3 days (1 day for processing and 2 days for technical monitoring of the system).

Second Rotation: During the 3 day processing period for the first set of logical queues, Authorized Registrars will submit additional Registered Name registration requests to their individual logical queues. After the third day, Registry Operator will randomize and process the queues as described above. The processing of the second set of logical queues is estimated to last 2 days (1 day for processing and 1 day for technical monitoring of the system).

Third Rotation: While the second set of logical queues are being processed, Authorized Registrars may submit additional Registered Name registration requests to their individual logical queues, and these requests will be processed in the same manner as the first and second queues. The processing of the third set of logical queues is estimated to last 2 days (1 day for processing and 1 day for technical monitoring of the system).

Fourth and Fifth Rotation: The fourth and fifth sets of logical queues will be collected and processed in the same manner as the third set of logical queues.

After the fifth set of logical queues has been processed, Registry Operator anticipates that the volume of Registered Name requests will allow the Registry System to move to a real-time registration process. Registry Operator reserves the right, in its reasonable discretion to implement additional rotations after the fifth rotation as a result of greater than anticipated volume.

Once the Registry System begins to process the final set of logical queues, Registry Operator will not accept additional Registered Name requests for two days. After such two days, when the final set of logical queues has been processed, Registry Operator will commence processing Registered Name registrations in real time as described in Section 4 below.

Once real-time Registered Name registration processing begins, Registry Operator will implement a policy under which Registrar may, at its discretion, cancel a Registered Name it submitted any time within five days after the registration was submitted to Registry Operator. During both the Sunrise and Land Rush Periods, however, this discretionary cancellation policy will not apply.

2. Operational Test & Evaluation

Before Registrar 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 Registrar's client system, and Registrar's capability to operate the interface with the Registry System; and

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

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

Registrar will be required to pass certain tests to be eligible to go live. 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 if Registrar fails to successfully complete the tests. Registrar may correct its systems and re-schedule for certification. Registrar will not be limited in the number of attempts at OT&E certification. Upon successful OT&E certification, Registrar becomes eligible for operation in the live registration environment.

3. Sunrise Period

Prior to opening the Registry System for general registration, Registry Operator will implement a Sunrise Period registration program.

Eligible Parties

During this Sunrise Period, owners of any current (non-expired) trademark or service mark registration having national effect (including, for example, European Community Trademarks (CTMs) but excluding United States state registrations) that issued prior to October 2, 2000 will be eligible to register a domain name that is identical to the textual or word elements of such trademark or service mark, using ASCII characters only, and subject to the same character and formatting restrictions as apply to all domain name registrations in the Registry TLD. Where there is a space between the textual elements of a mark, the Registrant may elect at their discretion to use a hyphen or combine the elements together. For example, the mark "SERVICE MARK" could be registered as servicemark.info or service-mark.info. Trademark or service mark registrations from the supplemental or equivalent registry of any country, or from individual states or provinces of a nation, will not be accepted.

Schedule for Sunrise Period

The Sunrise Period will be conducted as follows:

Announcement Period: At least forty-five to seventy-five (45 - 75) days prior to the commencement of the Land Rush Period, Registry Operator will make a general public announcement that will provide the following information: (i) the estimated Start Date for the Sunrise Period; (ii) the estimated termination date of the Sunrise Period; and (iii) the estimated Start Date for the Land Rush Period.

Sunrise Period: Following a minimum Announcement Period of at least fifteen to thirty (15 - 30) days, the Registry will begin processing Registered Name requests using the logical queue system set forth above. This Sunrise Period is scheduled to last for a minimum of thirty (30) days.

Cooling Off Period: After the conclusion of the Sunrise Period, Registry Operator reserves the right, at its sole discretion, to institute an "evaluation period" of fifteen (15) days. The purpose of such evaluation period is to provide Registry Operator the opportunity to evaluate the operation of the Registry System and round robin systems and to make any necessary modifications prior to the Land Rush Period. Registry Operator reserves the right to increase or decrease the Cooling Off Period in its reasonable discretion.

Processing

In order for trademark and service mark owners to qualify to receive a registration during the Sunrise Period (a "Sunrise Registration"), the following information must be provided to Registry Operator: (i) the ASCII characters name of the trademark or service mark; (ii) the date the registration issued; (iii) the country of registration; and (iv) the registration number. Registrar shall require this information, in addition to the standard information required of all potential registrants, be provided by potential Sunrise Period registrants. This information shall be included in the Whois informational database to facilitate the resolution of disputes over Sunrise Registrations. The Whois database shall be made available at the commencement of the Sunrise Period. Neither Registry Operator nor Registrar will verify any of this information prior to issuing a Sunrise Registration, but Registry Operator reserves the right to refuse or cancel any Sunrise Registration at any time and to request additional information relating to a Sunrise Registration from the registrant.

In the event that separate applicants submit Registered Name requests for identical trademarks, the first request to be processed by the Registry System that meets the criteria for a Sunrise Registration will be awarded the domain name registration.

Sunrise Registrations will only be accepted for registration terms of at least five years. A Sunrise Registration request will be filled only if Registrar has in place a mechanism to pay the registration fees for such registration, as described in the Agreement.

Registry Operator will prohibit the transfer of all domain names registered during the Sunrise Period for a period of up to six months following the last day of the Sunrise Period, except for transfers made as a result of a successful challenge, a decision in a Uniform Dispute Resolution Policy ("UDRP") administrative proceeding, or an order from any court of competent jurisdiction. In addition, Sunrise Registrations that are subject to one or more pending challenges (see "Sunrise Dispute Resolution Policy" below) may not be transferred until such challenges are resolved.

Sunrise Registrations shall otherwise be subject to the terms of this Agreement.

Sunrise Dispute Resolution Policy

All Sunrise Period Registered Name registrants will agree to be subject to the Sunrise Dispute Resolution Policy described herein for all disputes arising out of Sunrise Registrations.

A third party may challenge a Sunrise Registration on the following basis: (i) the Registered Name Holder did not own a current (non-expired) trademark or service mark registration; (ii) the trademark or service mark registration was not of national effect; (iii) the second level of the Registered Name is not identical to the trademark or service mark registration; or (iv) the trademark or service mark registration did not issue prior to October 2, 2000. All challenges will be subject to a challenge fee of US $295 upon assertion of the challenge. Parties may challenge Sunrise Registrations at any time during a period of one hundred twenty (120) days following the conclusion of the Sunrise Period. After such one hundred twenty (120) day period, parties disputing the validity of a Sunrise Registration must utilize the UDRP or available courts of law.

All dispute resolution proceedings involving Sunrise Registration challenges will be conducted in English, and any foreign language certificates submitted by the parties must be accompanied by certified translations. The Registered Name Holder and challenger may represent themselves in these proceeding or may be represented by legal counsel or other representatives.

Registry Operator, or its authorized third party dispute resolution providers, will administer challenges against Sunrise Period registrations as described below:

1. The challenger will electronically submit a notification to Registry Operator, in a form determined by Registry Operator, in which it sets forth the basis of the challenge, specifically identifies the Registered Name Holder by name, assumes a contractual obligation to pay the $295 challenge fee, arranges for payment terms for the challenge fee and notifies Registry Operator of such terms. Such terms must be agreeable to Registry Operator in its reasonable discretion. Registry Operator will electronically time stamp each request and forward a copy of the challenge to the domain name registrant and the registrar of record. In the case of multiple challenges to a single Sunrise Registration, the first party submitting a complete and accurate challenge will be given priority.

2. If the challenger fails to arrange for payment terms in a manner reasonably agreeable to Registry Operator, the challenge will be dismissed without prejudice, and, if other challenges to the Sunrise Registration remain, Registry Operator will process the next challenge, as shown by the timestamp on its challenge notice, in accordance with these dispute resolution procedures.

3. Upon arranging payment terms with the challenger, Registry Operator will send an electronic notice (email and/or facsimile) to the Registered Name Holder informing them that the challenge has been completed and will proceed. The Registered Name Holder will then have to arrange for payment terms of a $295 challenge fee and notify Registry Operator of such terms. Such terms must be agreeable to Registry Operator in its reasonable discretion. In addition, the Registered Name Holder shall have sixty (60) days from the date of notification of the completed challenge to submit a certified copy of its corresponding trademark or service mark registration, or other evidence sufficient to establish the existence of such registration, to Registry Operator or its authorized agent, when requested.

4. If the Registered Name Holder fails to arrange for payment terms agreeable to Registry Operator, or is unable to establish the existence of a current trademark or service mark registration within the allotted time, then the registrant will forfeit the domain name registration without refund of any registration or challenge fees.

5. If the domain name registrant arranges for payment terms agreeable to Registry Operator and establishes the existence of a trademark or service mark registration within the allotted time, Registry Operator or its designated agent will use commercially reasonable efforts to determine the merits of the challenge promptly within twenty (20) days of receipt of such terms and such registration information, and will notify the challenger and the Registered Name Holder of its decision promptly after its resolution.

6. If the Registered Name Holder arranges for payment terms agreeable to Registry Operator and the Registered Name Holder's trademark or service mark registration meets the criteria for a Sunrise Registration, then (i) such Registered Name Holder will retain the Registered Name, and (ii) Registry Operator will refund the Registered Name Holder's entire challenge fee. The unsuccessful challenger will forfeit its entire challenge fee.

7. If the Registered Name Holder arranges for payment terms agreeable to Registry Operator and the Registered Name Holder's trademark or service mark registration does not meet the criteria for a Sunrise Registration, then (i) such Registered Name Holder will forfeit the Registered Name without refund of any registration or challenge fees, and (ii) Registry Operator will place the Registered Name on a ten day hold.

8. During this ten-day hold period, Registry Operator will offer the prevailing challenger the option of registering the disputed domain name on its own behalf, provided that the challenger must provide the same information and agree to the same terms as required for Sunrise Registrations. If the challenger elects such option, the Registry will give it an authorization code to allow registration of the domain name through an Authorized Registrar.

9. If the prevailing challenger does not elect, or is not eligible, to register the domain name on its own behalf within the ten day hold period, then the authorization code and the option to register the domain name will be afforded to the first other challenger that submitted an accurate and complete challenge and arranged for payment terms of the challenge fee within the allotted time. The identification of such challenger will be based on the timestamp on its challenge. If no other such challengers exist, the Registered Name will be returned to the general pool of available domain names in accordance with Registry Operator's procedures for cancelled domain name registrations.

Outsourcing

Registry Operator reserves the right to outsource the dispute resolution procedures described in this Exhibit to a third party that, in Registry Operator's reasonable judgment, is qualified to conduct the dispute resolution process. Registry Operator reserves the right to develop, in consultation with such third party dispute resolution provider, supplemental rules to facilitate the dispute resolution procedure, provided that they are consistent with the policy set forth in this document.

4. Land Rush Period

Eligible Parties

Registry Operator will not impose any restrictions on who may register a domain name during the Land Rush Period, other than those restrictions that apply during the normal operation of the Registry System.

Schedule for Land Rush Period

The Land Rush Period will commence immediately after the conclusion of the Sunrise Period and any Cooling Off portion of the Sunrise Period.

Registry Operator will notify ICANN at least fifteen (15) days prior to the commencement of the Land Rush Period of its anticipated Start Date for the Land Rush Period. Promptly after the receipt of such notice, but in no event later than seven (7) days after the receipt of such notice, ICANN shall delegate the Registry TLD within the Authoritative Root Server System to nameservers designated by Registry Operator.

Registry Operator will provide a general public announcement stating the Start Date for the Land Rush Period at least five (5) days before the commencement of such period. The Land Rush Period will continue so long as necessary for Registry Operator to conclude its processing of queued registrations. Upon the conclusion of the Land Rush Period, Registry Operator will transition to real-time registration as described above.

Processing

All Registered Name requests received during the Land Rush Period will be processed using the logical queue system described above. These registrations may not be transferred until sixty (60) days after the conclusion of the Land Rush Period, absent a decision in a UDRP administrative proceeding or an order from any court of competent jurisdiction. All Land Rush Registrations will be for a minimum period of two (2) years.

Dispute Resolution

All Land Rush Registered Name registrants will agree to be subject to the UDRP for disputes arising out of Land Rush registrations, and shall be subject to the terms of the Authorized Registrar's Registry-Registrar Agreement with Registry Operator.

5. Register Domain Names

If the Effective Date of the Agreement was at least ten (10) days prior to the beginning of the Land Rush Period, Registrar shall have the right to register up to ten (10) Registered Names ("Registrar Registrations") in the Registry TLD, provided that the desired Registrar Registration (i) was not reserved or previously registered, (ii) is a trade name, trademark or service mark of the Authorized Registrar, and (iii) is identical to a name registered by the Authorized Registrar in either the .com or .net TLD.

Processing

Registrar shall submit its list of desired Registrar Registrations to Registry Operator at least ten (10) days prior to the beginning of the Land Rush Period. Registry Operator shall process such Registrar Registrations promptly upon receipt thereof.
Registry Operator shall charge Registrar its standard registration fee for each Registrar Registration.

Dispute Resolution

In the event of a dispute between Authorized Registrars over a desired Registrar Registration, Registry Operator shall grant the Registrar Registration to the Authorized Registrar that first registered the identical name in the .com or .net TLD, as reflected in the records of the registry for the .com and .net TLDs.
Registrars acknowledges that its registration of Registrar Registrations is subject to the UDRP, and shall be subject to the terms of the Agreement.

6. Phase-in of Name Resolution

For Sunrise Registrations and Registrar Registrations, Registered Names will resolve seven (7) days after the beginning of the Land Rush Period.

For Land Rush registrations, Registered Names will resolve within five (5) minutes of their successful processing by the Registry System.

7. Public Notification Mechanisms

Registry Operator will work in conjunction with ICANN, the intellectual property constituency and the Internet community at large to maximize the notification process by using a multitude of mechanisms including: the Registry Operator web site, email announcements; Registrar communiqués; press releases; as well as articles and general advertisements.

Announcements regarding the timing of the Start Date for the Sunrise Period and the Land Rush Period, and of the Sunrise Period and Land Rush Period logical queue rotations will, at a minimum, be available on the Registry Operator web site.

8. Summary of Anticipated Schedule

Registry Operator anticipates that the Sunrise and Land Rush Periods will observe the following schedule.

1. Domain-Name Initial Registration Fee

Registry Operator will charge US $5.75 per year for each domain name registered (the "Initial Registration Fee") in the Registry TLD. The Initial Registration Fee shall be paid in full by Registrar sponsoring the domain name at the time of registration.

2. Domain-Name Renewal Fee

Registry Operator will charge US $5.75 per year for each domain name registration renewal (the "Renewal Fee") in the Registry TLD. The Renewal Fee shall be paid in full by Registrar sponsoring the domain name at the time of renewal.

3. Fees for Transfers of Sponsorship of Domain-Name Registrations

Where the sponsorship of a domain name is transferred from one ICANN-Accredited Registrar to another ICANN-Accredited Registrar, Registry Operator will require the registrar receiving the sponsorship to request a renewal of one year for the name. In connection with that extension, Registry Operator will charge a Renewal Fee for the requested extension as provided in item 2 above. The transfer shall result in an extension according to the renewal request, subject to a ten-year maximum on the future term of any domain-name registration. The Renewal Fee shall be paid in full at the time of the transfer by the ICANN-Accredited Registrar receiving sponsorship of the domain name.

4. ICANN Variable Fees

The pricing for initial and renewal registrations set forth above shall be adjusted pursuant to Section 3.14.5 of the Registry Agreement between Registry Operator and ICANN.

5. Bulk Transfer Fee

For a bulk transfer approved by ICANN under Part B of Exhibit D, Registry Operator will charge the gaining registrar US $0 (for transfer of 50,000 names or fewer) or US $50,000 (for transfers of more than 50,000 names).

1. Definitions Capitalized terms used herein and not otherwise defined shall have the meaning ascribed to them in the Registry-Registrar Agreement.

1.1 "Current Pricing Level" refers to prices charged for Registry Services as provided in Appendix G of the Registry Agreement as adjusted pursuant to Subsections 3.14.5 and 4.4 of the Registry Agreement.

1.2 "C1" means Category 1, a mission critical service.

1.3 "C2" means Category 2, a mission important service.

1.4 "C3" means Category 3, a mission beneficial service.

1.5 "Degraded Performance" means a service not meeting the performance requirement set forth in this document. Round-trip time is used as the basis of this metric for all services except nameservice; for nameservice packet loss and Round-trip time are used as metrics.

1.6 "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 the Greenwich Mean Time (GMT).

1.7 "Monthly Unplanned Outage Time" shall be the sum of minutes of all Unplanned Outage Time during the Monthly Timeframe. Each minute of Unplanned Outage Time subtracts from the available Monthly Planned Outage Time up to four (4) hours.

1.8 "Not Responding" means a service will be deemed as "Not Responding" in the event that the Network/Application Monitoring Service responds with a negative or degraded service response.

1.9 "Planned Outage" means the periodic pre-announced occurrences when the System will be taken out of service for maintenance or care. Planned Outages will be scheduled only during the following window period of time each week, 0100 to 0900 GMT on Sunday (the "Planned Outage Period"). This Planned Outage Period may be changed from time to time by the Registry Operator, in its sole discretion, upon prior notice to each Registrar. Planned Outages will not exceed four (4) hours/per calendar week beginning at 00:00 am GMT Monday nor total more than eight (8) hours/per calendar month. Planned Outage for a nameserver shall not coincide with or overlap Planned Outage for any other nameserver. Notwithstanding the foregoing, in each calendar year Registry Operator may incur one (1) additional Planned Outage of up to eight (8) hrs in duration during the Planned Outage Period for major systems or software upgrades ("Extended Planned Outages"). This Extended Planned Outage represents the total allowed Planned Outages for the month.

1.10 "Round-trip" means the amount of measured time that it takes for a reference query to make a complete trip from the sampling agent, to the system or process being tested and back again. Usually measured in milliseconds.

1.11 "Service Availability" means when the System is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages.

1.12 "Service Unavailability" means when, as a result of a failure of systems within the Registry Operator's control.

1.12.1 With respect to services other than Whois Service and nameservice, Registrar is unable to establish a session with the System gateway which shall be defined as:

1.12.1.1 successfully complete a TCP session start,

1.12.1.2 successfully complete the SSL authentication handshake, and

1.12.1.3 successfully complete the Extensible Provisioning Protocol ("EPP") <login> command.

1.12.2 With respect to all services, system monitoring tools register three (3) consecutive monitoring failures on any of the components listed in Section 2 - System Services.

1.13 "SLA" means this Service Level Agreement between Registry Operator and Registrar.

1.14 "SLA Credit" means those credits available to the Registrar pursuant to the SLA.

1.15 "System" shall mean the list of components listed in Section 2 - System Services.

1.16 "Transaction" shall mean chargeable Registry Services, which includes initial and renewal registrations.

1.17 "Unplanned Outage Time" shall mean all of the following:

1.17.1 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in response to a Registrar's claim of Service Unavailability for that Registrar through the time when the Registrar and Registry Operator agree the Service Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered Service Unavailability only for those individual Registrars impacted by the outage;

1.17.2 With respect to services other than Whois Service and nameserver resolution, the amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event of Service Unavailability that affects all Registrars through the time when the Registry Operator resolves the problem with a final fix or a temporary work around, and the trouble ticket has been closed;

1.17.3 With respect to all services, the amount of time that Planned Outage time exceeds the limits established in Section 1.10 above; or

1.17.4 With respect to all services, the amount of time that Planned Outage time occurs outside the window of time established in Section 1.10 above.

1.18 "Whois Service" means the Registry Operator Whois Services described in Appendix O of the Registry Agreement.

2. System Services

The following table lists, by category (C1, C2, or C3), the Registry System services for which availability and performance requirements are established. Services shall meet availability requirements according to their category, as listed in the "Cat." column below. In addition, various services must meet the performance requirements listed in the "Perf." column below. These availability and performance requirements are the subject of the SLA between Registry Operator and Registrars.

Component/Service	Cat.	Perf.
DNS
AXFR/IXFR Updates	C3
Billing		P5
Account balance check/modify	C2
Manual balance adjust	C3
Admin
Update Registrar profile	C3
Update Registrar status	C3
Protocol Interface
Add/Renew/Delete/ Update	C1	P1
Transfer	C1	P6
Check	C1	P2

3. Service Levels (Availability and Performance)

C1	Total duration of Unplanned Outage Time of C1 class services must not exceed 30 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.93%.
	Total duration of Service Unavailability of C1 class services must not exceed 60 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.86%.
C2	Total duration of Unplanned Outage Time of C2 class services must not exceed 90 minutes per monthly Timeframe. This represents a Service Availability percentage of 99.79%.
	Total duration of all Service Unavailability of C2 class services must not exceed 180 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.65%.
C3	Total duration of Unplanned Outage Time of C3 class services must not exceed 300 minutes per Monthly Timeframe. This represents a Service Availability percentage of 99.30%.
	Total duration of all Service Unavailability of C3 class services not to exceed 600 minutes per Monthly Timeframe. This represents a Service Availability percentage of 98.61%.
P1	For a single-entity payload, Round-trip time should not exceed 800ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.
P2	For a single-entity payload, Round-trip time should not exceed 400ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple-entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.
P5	See Subsection 5.14 below.
P6	For a single-entity payload, Round-trip time should not exceed 1600 ms as measured by the system monitoring tools that simulates a representative registrar. A request with a multiple-entity payload should materially perform consistent with the behavior of multiple, single entity payload operation.

4. Credits

4.1 C1–If availability of C1 class services exceeds C1 Service Levels in any given calendar month, Registry Operator will credit Registrar according to this calculation;

C = (amv/t)*sle

Where:

C	=	number of Transactions to be credited to Registrar for the calendar month.
amv	=	average month's volume (previous four calendar months total Transaction volume/4 months).
t	=	time period, number of minutes per month averaged over number of days in previous four calendar months (for example, if previous four months had 30, 31, 30, 31 days, these time period = (30 + 31 + 30 + 31)/4 * 24 hours * 60 minutes = 43,920 minutes).
sle	=	service level exception. The number of Unavailable minutes minus the number of SLA acceptable Unavailable minutes.

Example:

Registry Operator records 15 minutes of service level exception beyond the time periods contemplated by the SLA. The current amv is 30,000 total names registered and time period was 43,920 minutes. As such, Registry Operator will credit Registrar for 10.25 Transactions at the then Current Pricing Level.

4.2 C2–If availability of C2 class services exceeds C2 Service Levels in any given calendar month, Registry Operator will credit Registrar according to this calculation;

C = (amv/t)*sle * 60%

Where:

C	=	number of Transactions to be credited to Registrar for the calendar month.
amv	=	average month's volume (previous four calendar months total Transaction volume/4 months).
t	=	time period, number of minutes per month averaged over number of days in previous four calendar months (see example in Subsection 4.1).
sle	=	service level exception. The number of Unavailable minutes minus the number of SLA acceptable Unavailable minutes.
60%	=	priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the time periods contemplated by the SLA. The current amv is 30,000 total names registered and time period was 43,920 minutes. As such, Registry Operator will credit Registrar for 6.15 Transactions at the then Current Pricing Level.

4.3 C3–If availability of C3 services exceeds C3 Service Levels in any given calendar month, Registry Operator will credit Registrar according to this calculation;

C = (amv/t)*sle * 30%

Where:

C	=	number of Transactions to be credited to Registrar for the calendar month.
amv	=	average month's volume (previous four calendar months total Transaction volume/4 months).
t	=	time period, number of minutes per month averaged over number of days in previous four calendar months (see example in Subsection 4.1).
sle	=	service level exception. The number of Unavailable minutes minus the number of SLA acceptable Unavailable minutes.
30%	=	priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the time periods contemplated by the SLA. The current amv is 30,000 total names registered and the time period was 43,920 minutes. As such, Registry Operator will credit Registrar for 3.07 Transactions at the then Current Pricing Level.

4.4 Degraded Performance–If the performance of the transactive systems (OpenXRS API, Whois) exceed the performance expectations outlined in Service Levels over the month in question, Registry Operator will credit Registrar according to this calculation;

C = (amv/t)*sle * 7.5%

Where:

C	=	number of Transactions to be credited to Registrar for the calendar month.
amv	=	average month's volume (previous four calendar months total Transaction volume/4 months).
t	=	time period, number of minutes per month averaged over number of days in previous four calendar months (see example in Subsection 4.1).
sle	=	service level exception. The number of Unavailable minutes minus the number of SLA acceptable Unavailable minutes.
7.5%	=	priority adjustment.

Example:

Registry Operator records 15 minutes of service level exception beyond the time periods contemplated by the SLA. The current amv is 30,000 total names registered and time period was 43,920 minutes. As such, Registry Operator will credit Registrar for 0.77 Transactions at the then Current Pricing Level.

4.5 Receipt of Credits–In order for registrars to claim credits, the following procedure must be followed:

4.5.1 Issue a Request for SLA Credits.

The claiming registrar must make a request for credits to Registry Operator claiming that it experienced downtime or degraded performance in excess of what is outlined in this Exhibit.

4.5.2 Provide documentation to indicate SLA Violation.

A Registrar may provide documentation in the form of either:

4.5.2.1 Registrar initiated notification(s) to the Registry Operator of a down time that exceeded SLA limits, including the trouble ticket number issued by the Registry Operator. The closing ticket(s) should be included as well in order to determine the total downtime (unless the closing ticket includes this); or

4.5.2.2 Notification from the Registry Operator (with trouble ticket number attached) of down time or degraded performance. The closing ticket(s) should be included as well in order to determine the total downtime (unless the closing ticket includes this).

4.5.3 Justification of Volume.

In order to calculate credits, the Registrar should include volume figures for the past four (4) calendar months, and a certification that these numbers accurately reflect the LEAST registration activity that would be covered during the affected SLA outage.

4.5.4 Receipt of Credit.

When the above steps have been completed to the Registry Operator's satisfaction, the Registry Operator shall provide notification of the number of credits that will be entered in the Registrar's account balance and that can be used immediately toward registrations in the Registry.

5. Responsibilities of the Parties

5.1 Registrar will assist Registry Operator by reporting each occurrence of alleged Service Unavailability to Registry Operator customer service help desk in the manner required by Registry Operator (i.g., e-mail, fax or telephone) in order for an occurrence to be treated as Service Unavailability for purposes of this SLA. Registry Operator will treat all system performance problems in order of decreasing severity and fix them within a commercially reasonable period of time. Incidents flagged by the measurement system will also qualify as ticketed events and will be classed as Unavailability.

5.2 Registry Operator will perform monitoring from internally located systems as a means to verify that the conditions of the SLA are being met.

5.3 The SLA will be reconciled on a quarterly basis.

5.4 The Registrar will have the option to choose which of the credit calculations described in Subsection 4 of this SLA will apply where service level credit overlaps occurs. There can be several types of credits over the same calendar month, but the Registrar can only claim one type of refund for each event.

5.5 Registry Operator will not attempt to discern what discount levels were in effect at the specific time of a service level exception, but rather use the discount level in effect at the time the credits issue. All service level credits will be paid out using the appropriate discounts and rate levels reflected by the then current rate schedule.

5.6 The Registrar may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying service level performance. The frequency of these audits will be no more than once every six month period during the term of the Registry-Registrar Agreement between Registry Operator and the Registrar.

5.7 Registry Operator's obligations under this SLA are waived during the first 120 days after the Commencement-of-Service Date.

5.8 Incident trouble tickets must be opened within a commercially reasonable period of time.

5.9 In the event that Service Unavailability affects all Registrars, the Registry Operator is responsible for opening a blanket trouble ticket and immediately notifying all Registrars of the trouble ticket number and details.

5.10 Both Registrar and the Registry Operator agree to use reasonable commercial good faith efforts to establish the cause of any alleged Service Unavailability. If it is mutually determined to be a Registry Operator problem, the issue will become part of the Unplanned Outage Time.

5.11 Registrars must inform the Registry Operator any time their estimated volume of transactions (excluding check domain commands), will exceed their previous calendar month's volume by more than 25%. In the event that a Registrar fails to inform Registry Operator of a forecasted increase of volume of transactions of 25% or more and the Registrar's volume increases 25% or more over the previous month, and should the total volume of transactions added by the Registry Operator for all Registrars for that month exceed the Registry Operator's actual volume of the previous month's transactions by more than 20%, then the Registrar(s) failing to give such notice will not be eligible for any SLA Credits in that Monthly Timeframe. Registrars shall provide their forecasts at least 30 days prior to the first day of the next calendar month. In addition, the Registry Operator agrees to provide monthly transaction summary reports starting no later than 120 days after the Commencement-of-Service Date.

5.12 The Registry Operator will notify Registrar of Planned Outages outside the Planned Outage Period at least 7 days in advance of such Planned Outage. In addition, Registry Operator will use reasonable commercial good faith efforts to maintain an accurate 30 day advance schedule of possible upcoming Planned Outages.

5.13 The Registry Operator will update the Whois Service on a near real-time basis. During normal operation, all registration and information updates sent from a Registrar to the Registry are stored in the primary database (database A). The information in database A is replicated to a backup database (database B) at regular intervals, normally within five (5) minutes. The Whois service uses database B as its source of information. The time lag in the Whois information update is determined by the database replication interval. The Registry Operator will notify Registrars in advance when changes to the Whois Service update schedule occur.

5.14 The Registry Operator will initiate the addition, deletion or other modification of DNS zone information to the master DNS server within 5 minutes of a Transaction. The Registry Operator will notify Registrar in advance when changes to the schedule occur. The Registry Operator will notify Registrars regarding any scheduled maintenance and unavailability of the TLD root-servers.

5.15 The Registry Operator will use commercially reasonable efforts to restore the critical systems of the System within 24 hours in the event of a force majeure and restore full system functionality within 48 hours. Outages due to a force majeure will not be considered Service Unavailability.

5.16 Beginning no later than 120 days after the Commencement-of-Service Date, the Registry Operator will publish preliminary weekly system performance and availability reports. Registry Operator will use best efforts to finalize these reports no later than 30 days after the preliminary reports are provided.

5.17 The Registry Operator will provide Service Availability percentages during each Monthly Timeframe as listed in Section 3 - Service Levels of this Exhibit.

6. Miscellaneous

6.1 This Exhibit is not intended to replace any term or condition in the Registry-Registrar Agreement.

6.2 Dispute Resolution will be handled pursuant to the arbitration provisions of the Registry-Registrar Agreement.