Unsponsored TLD Agreement: Appendix F (.name)

(3 July 2001)

This Registry-Registrar Agreement (the "Agreement") is between The Global Name Registry Ltd., a company, with its principal place of business located in 125 High Holborn, LONDON, WC1V 6QA, United Kingdom ("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 .name top-level domain;

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

WHEREAS, Registrar wishes to act as a registrar for domain names and other Registered Items (as defined herein) within the .name top-level domain.

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

1. DEFINITIONS

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

1.2. "Confidential Information" means all information and materials, including, without limitation, computer software, data, 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. "Defensive Registration" means a registration granted to a third party of a specific string on the second or third level, or of a specific set of strings on the second and third levels, which will not resolve within the DNS but may prevent the registration of the same string(s) on the same level(s) by other third party applicants. Defensive Registrations are fully described in Appendix L to the Registry Agreement.

1.4. "Defensive Registration Holder" means the holder of a Defensive Registration.

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

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

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

1.8. "NameWatch Registration" means a registration of a specific string in the NameWatch Service (as described in Appendix J to the Registry Agreement.

1.9. "NameWatch Registration Holder" means the holder of a NameWatch Registration.

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

1.11. "Registered Items" means, collectively, Registered names, SLD E-mail Addresses, Defensive Registrations and NameWatch Registrations.

1.12. "Registered Item Holders" means the holders of Registered Items.

1.13. "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 zone file (e.g., a registered but inactive name).

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

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

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

1.17. "Registry Database" means a database comprised of data about one or more DNS domain names, SLD E-mail Addresses and Defensive Registrations 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 look up requests or Whois queries, for some or all of those names.

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

1.19. The "Registry System" means the system operated by Registry Operator for Registered Items.

1.20. "Registry TLD" means the .name TLD.

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

1.22. "SLD E-mail Address" means an e-mail address consisting of a second level domain name within the domain of the Registry TLD and a defined user name (e.g., john@smith.name), 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.

1.23. "SLD E-mail Address Holder" means the holder of an SLD E-mail Address.

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

1.25. 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 Items 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 five working 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 to 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 Registered Item registration services in the Registry TLD only and for no other purpose.

Subject to the foregoing paragraph, software included within the Registrar Took Kit shall be subject to the GNU Lesser Public General License (LGPL), a copy of which may be found at <http://www.gnu.org>. If Registry Operator elects to modify or upgrade the APIs and/or the RRP, Registry Operator shall provide such updated APIs to the RRP with documentation and updated software to Registrar promptly as such updates become available.

2.4 Changes to System. Registry Operator may from time to time make modifications to the RRP, APIs, materials or other software 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.
This notice period shall not apply in the event Registry Operator's system is subject to the imminent threat of a failure or a material security threat, or the discovery of a major security vulnerability or a Denial of Service (DoS) attack where the Registry Operator's systems are rendered inaccessible by being subject to (i) excessive levels of data traffic, (ii) unauthorized traffic; or (iii) data traffic not conforming to the protocols used by the Registry Operator's system.

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 from time to time 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. Registrar shall provide all such information to its registrants promptly upon receipt from Registry Operator. 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. Registry Operator shall be responsible for notifying Registrar of events that affect the performance of the Registry System.

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 services including, but not limited to (i) support to accept orders for registration, cancellation, deletion or transfer of Registered Items and (ii) customer service (including Registered Item record support) and billing and technical support to Registered Item Holders.

3.3 Registrar's Registration Agreement. At all times while it is sponsoring the registration of any Registered Item within the Registry System, Registrar shall have in effect an electronic or paper registration agreement with the Registered Item Holder. The initial form of Registrar's registration agreement is attached as Exhibit C (which may contain multiple alternative forms of the registration agreement). Registrar may from time to time amend those forms of registration agreement or add alternative forms of registration agreement, provided a copy of the amended or alternative registration agreement is furnished to the Registry Operator ten (10) working 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 Item Holders. In its registration agreement with each Registered Item Holder, Registrar shall require such Registered Item 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 Item Holder's 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 Item 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 under any 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 Items 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 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 Registered Items or to 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 Registered Item registration into the Registry Database, the time shown in the Registry Operator's records shall control.

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

3.11 Restrictions on Registered Items. In addition to complying with ICANN standards, policies, procedures, and practices limiting Registered Items that may be registered, and Registry Operator policies pursuant to Subsection 3.5, Registrar agrees to comply with applicable statutes and regulations limiting the Registered Items that may be registered.

3.12 Changes in Volume. Registrar must inform Registry Operator any time its estimated volume of transactions (excluding check domain commands) will exceed its previous month's volume by more than twenty-five percent (25%). Failure to so inform Registry Operator may result in a reduction of credits issued to Registrar by Registry Operator, as described in Exhibit G.

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 or which may in the future be 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 prepaid account facility or such other facility as may be agreed between the parties. The prepaid account facility will be subject to the following criteria:

4.2.1 Registrar may remit funds to its prepaid account at times and in amounts of Registrar's choosing. These funds will be added to Registrar's prepaid account.

4.2.2 Registrar's account shall be maintained in United States dollars or such other currency as Registry Operator may designate from time to time.

4.2.3 Fees incurred by Registrar will be deducted from the Registrar's prepaid account when incurred. Refunds of fees due to the Registrar will be added on to Registrar's prepaid account.

4.2.4 Registry Operator will only provide Fee-based services under this Agreement if Registrar has sufficient funds in its prepaid account to cover the requested activity plus any direct or indirect taxation that may be due. It shall be Registrar's responsibility to ensure that an adequate level of funds is maintained in its prepaid account to allow for uninterrupted business.

4.2.5 Registry Operator will maintain a record of funds received and Fees incurred by Registrar and will make such record available to Registrar for reconciliation purposes.

4.2.6 No interest will be paid on prepaid accounts.

4.3 Deletions and Refunds. Within one hundred twenty (120) hours after registering or renewing any Registered Item, Registrar may cancel such registration or renewal without cause and request a full refund of the Fees incurred for such registration or renewal. Registry Operator will provide such refund only if Registrar cancels the Registered Item within such period using the appropriate command in the RRP. Registry Operator shall not grant refunds under any other circumstances. Deleted Registered Items shall be available for new registration immediately.

4.4 Receipts of Funds. Funds for Registrar's prepaid account shall be wired as immediately available funds to a bank account designated from time to time by Registry Operator. Registry Operator shall add such funds to Registrar's prepaid account balance only after Registry Operator receives confirmation from its bankers of the deposit of funds in Registry Operator's account. Registry Operator shall not be responsible for any delays in the wiring of funds. The amount of funds recognized and added to Registrar's prepaid account shall be net of any bank charges or currency exchange charges. Where currency is exchanged in the course of the wire transfer, the exchange rate determined by Registry Operator's bank shall govern.

4.5 Invoicing. Within thirty (30) days after the end of each calendar month, Registry Operator shall provide Registrar with an invoice showing the Fees incurred during such calendar month and the remaining balance in Registrar's prepaid account.

4.6 Return of Prepayment Balance. Registrar may request, at any time, that Registry Operator return all or part of the funds in Registrar's prepaid account. Such request must be made to Registry Operator's designated account manager for such Registrar. Registry Operator shall remit such return to Registrar within seven (7) business days after receipt of Registrar's request by such account manager.

4.7 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 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 rights 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 Item Holder or Registrar; or (iii) relating to Registrar's Registered Item registration business, including, but not limited to, Registrar's advertising, Registered Item 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 its 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 laws of [insert Country, State], (ii) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (iii) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, and (iv) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement.

6.3 Limitation of Liability. IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES RESULTING FROM LOSS OF PROFITS OR BUSINESS INTERRUPTION ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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, an adequate Liability and Indemnity insurance policy to the value of USD 500,000 from a reputable insurance provider and shall maintain insurance meeting these requirements throughout the Term of this Agreement. Registrar shall provide a copy of the insurance policy and proof of paid premiums 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 England, United Kingdom. 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 arbitrators shall have the right to award attorney fees. The arbitrators shall render their decision within ninety days of the initiation of arbitration. 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 from any court of competent jurisdiction, 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 the said executed amendment or notice of termination within the fifteen day period stated above, Registrar shall be deemed to have terminated this Agreement on the expiration of the said fifteen day period.

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 Section 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 Registered Items 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 Items 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.1, 10.2, 10.3, 10.4, 10.6, 10.7 and 10.8 and (ii) the Registered Item 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 party has given a notice of a change of address in writing:

If to Registrar:
with a copy to:
If to Registry Operator:
	Global Name Registry Ltd. 125 High Holborn London WC1V 6QA United Kingdom Telephone: 44/207/025-2200 Facsimile: 44/207/242-9105 Attention: General Counsel
with a copy to:
	Rita A. Rodin Skadden, Arps, Slate, Meagher & Flom, LLP Four Times Square New York, NY 10036-6522 United States Telephone: +1/212/735-3000 Facsimile: +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 Item. Registrar expressly acknowledges that, notwithstanding anything in this Agreement to the contrary, it is not a third-party beneficiary of the Registry Agreement.

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

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

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

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

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

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

10.10 Governing Law. This Agreement is governed by the laws of England and Wales.

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

THE GLOBAL NAME REGISTRY LTD.		[Registrar]
By:		By:
Name:		Name:
Title:		Title:

 

---

EXHIBIT A

REGISTRAR TOOL KIT

Registry Operator will provide software to registrars enabling them to write client applications to interface with the Registry System interface. This software will consist of a Java API with sample code and C/C++ sample code.

Examples of XML message assembly will be shown in the sample code in addition to code illustrating how static XML requests can be sent to Registry Operator. The Registrar Tool Kit will give the Registrar a reference implementation that conforms to the RRP.

The Registrar Tool Kit will also contain documentation explaining the protocol specification in detail. Information included in this documentation will contain the format of request messages and possible response messages, as well as command sequences and message assembly rules for each SRS operation.

Descriptions of the software implementing the RRP specification will be in the documentation. This includes details about the software package hierarchy and explanations of the objects and methods defined within.

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

EXHIBIT B

ENGINEERING AND CUSTOMER SERVICE SUPPORT

Customer Service Support

During the Term of this Agreement, Registry Operator shall provide reasonable telephone, fax and e-mail customer service to Registrar, not Registered Item Holders or prospective customers of Registrar, for any issues relating to the Registry System and its operations.

Upon Registrar's request to become an authorized registrar for the Registry TLD, Registry Operator will assign Registrar a dedicated Account Manager. The Account Manager will be the primary contact point for Registrar, to whom queries of any nature may be directed. Registrars will conduct the majority of interactions with the Registry Operator through its Customer Service Department and the dedicated Account Manager, each of which will be responsible for escalating all queries according to the Escalation Procedures as described this Exhibit.

In addition to the assistance of the Customer Service Department and dedicated Account Manager, Registry Operator shall also provide a web-based knowledge base for FAQs and reference materials, as well as a web-based trouble-ticketing system interface. The web interface for the knowledge base will become available after signature of the Registry Agreement prior to the launch of the Registry TLD. The web-based trouble ticketing system will be operational before or concurrent with the launch of the Live SRS, as identified in Appendix J to the Registry Agreement.

Customer Service System (CSS) and Escalation Procedures

Registry Operator will use an escalation procedure to evaluate the priority of an issue and respond accordingly during the course of the query resolution process. Escalation will be used to ensure that all queries are dealt with in a timely manner using all reasonable commercial and technical means.

The system and procedures the Registry Operator maintains are collectively referred to as the Customer Service System (CSS). The Customer Services System and associated escalation procedures described below will be operational before or concurrent with "Commencement-of-Service Date," as defined in the Registry Agreement. Each telephone call, e-mail, fax, and/or postal mail received from Registrar raising a problem/query will be given a unique reference number, or "ticket," to facilitate ease of tracking and escalation. Support calls or other forms of communication shall be escalated as deemed necessary by support staff who shall be trained in the appropriate procedures. Issues can be escalated manually by the staff, or automatically by the CSS issue ticketing and tracking system.

CSS Security: The Registrar must supply a list of no more than 10 named individuals that are authorized to contact the Registry Operator by phone or email. Each of these individuals will be assigned a unique pass phrase such that the Registry Operator can then authenticate the authorized Registrar representatives. Registrar will also designate the primary and secondary CSS Security List Managers, who are authorized to modify the list of 10 representatives.

Examples of when escalations might occur include:

• Registrar needs an immediate answer to an urgent query that has not been previously resolved.
  
• Registrar is dissatisfied with the product, systems or services provided.
  
• The employee receiving the request does not have the authority or sufficient knowledge to resolve the query.
  

Escalation Priority Levels

Escalation priority levels are explained below from the highest to the lowest priority:

Priority 1: A "major production system" is down or severely impacted. Priority 1 issues are likely to be categorized as catastrophic outages that affect the overall Registry System operations and thereby all Registrars.

Priority 2: Registrar has a serious issue with a "primary feature" necessary for daily operations for which no work-around has been discovered and which completely prevents the feature from being used. Priority 2 issues will likely affect more than one registrar.

Priority 3: Registrar has an issue with a "non-critical feature" for which a work-around may or may not exist. Priority 3 issues may be unique to one Registrar.

Priority 4: Registrar has a "general enquiry," usage question, or feature enhancement request.

ESCALATION PATHS FOR PRIORITIES	STEPS FOR EACH PRIORITY LEVEL (Escalation paths describe the pre-defined route a query shall take)
Priority 1: "Major Production System"	Step 1: Request is received through a Customer Service Representative (CSR), the dedicated Account Manager, or the emergency line.
	Step 2: Request is escalated immediately to the Operations Manager and/or the appropriate technical operations staff.
	Step 3: If the Operations Manager and/or technical operations staff are unable to resolve the issue in a timely manner it is escalated to the Chief Technology Officer (CTO) and/or other members of the Executive Committee.
Priority 2 & 3: Primary Features or  Non-Critical Features	Step 1: Request is received through a Customer Service Representative (CSR) or the dedicated Account Manager.
	Step 2: If not resolved the request is escalated to the Customer Service Manager or Operations Manager who ensures that request is resolved, drawing on technical operations staff and/or finance/billing support.
	Step 3: If the Customer Service or Operations Staff are unable to resolve the problem the request is escalated to the CTO and/or other members of the Executive Committee.
Priority 4: General Enquiry	Step 1: Request is received by CSR or dedicated Account Manager.
	Step 2: If not resolved, the request is escalated to the Customer Service Manager or Operations Manager.
	Step 3: If the Customer Service Manager or Operations Manager is unable to resolve the issue it is escalated appropriately.

 

Escalation Patterns by Communication Channel.

There are three main channels of communication through which an issue can be brought to the attention of the Registry Operator: the Customer Service Department, the dedicated Account Managers and the emergency line. Escalation paths for these channels are outlined below:

Emergency Line Escalation Path:

Step 1: The customer calls the emergency telephone number, which will be answered by a qualified technical operations engineer on duty 24X7.

Step 2: The engineer discusses problem with the customer and verifies that the problem is a valid Priority 1 issue. If the problem is not deemed to be Priority 1, the engineer will make an entry in the CSS and refer the case to a CSR and the dedicated Account Manager for resolution. If the problem is a Priority 1 issue, the engineer starts resolving the problem immediately. If the issue cannot be resolved satisfactorily within the first 15 minutes, the case will be escalated to field engineers, the Operations Manager, the Chief Technology Officer, and/or other members of the Executive Committee as required to expedite the issue resolution.

Step 3: After resolving the issue the engineer makes an entry in the CSS, changes the request status to "resolved," and then calls or emails the customer back directly (as well as the CSR and/or dedicated Account Manager) to describe how the issue was resolved.

If resolution of the issue takes longer than 15 minutes the Registrar (and dedicated Account Manager) will be given periodic updates (at a minimum - every 30 minutes) via telephone and/or email.

Customer Service Department & Account Manager Escalation Paths: The Customer Service Department and dedicated Account Manager will, as the Registrar's primary point of contact, deal with all enquiries, with the exception of calls through the emergency line.

Step 1: The Customer Service Department and/or Account Manager receives a request, either by telephone, email, fax, or postal mail.

Step 2: If not able to resolve the issue in a timely manner, the CSR would ensure the Account Manager is notified, evaluate the severity of the request, assign a priority and make an entry into the CSS. The CSR and/or Account Manager would also then assign an owner, for example: the Customer Service Manager, the Operations Manager, technical support staff and/or finance/billing support.

Step 3: If the new owner of the request cannot resolve the issue, the relevant Department Head is notified.

Step 4: If the Department Head cannot resolve the issue it is escalated to the Chief Technology Officer and/or other members of the Executive Committee. The above process creates the ability to track any unresolved issues until a workaround or fix is provided.

Targeted Response Times: Prior to or on the "Commencement-of-Service Date" Registry Operator aims to ensure that 80% of all responses are within the following Targeted Response Times:

Priority	Description	Response Time	Resolution Time
Priority 1	A "major production system" is down or severely impacted.	Action taken as soon as reported	60 minutes
Priority 2	A serious issue with a "primary feature" necessary for daily operations.	First level analysis: 2 hours	12 hours
Priority 3	An issue with a "non-critical feature" for which a work-around may or may not exist.	First level analysis: 24 hrs	TBD
Priority 4	A "general enquiry" or request for feature enhancement.	48 hours	TBD

EXHIBIT C

REGISTRAR'S REGISTRATION AGREEMENT

[To be supplied by Registrar]

EXHIBIT D

POLICY ON TRANSFER OF SPONSORSHIP OF REGISTRATIONS BETWEEN REGISTRARS

A. Holder-Authorized Transfers.

Registrar Requirements.

The registration agreement between Registrar and its Registered Item Holder shall include a provision explaining that a Registered Item Holder will be prohibited from changing its Registrar during the first 60 days after initial registration of the Registered Item 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 Registered Item registration.

The gaining Registrar shall check the "hold" status of the Registered Item in question before proceeding with the Registered Item transfer procedure. If the Registered Item is on hold for any reason the Registrar is notified and the transfer process is terminated.

For each instance where a Registered Item Holder wants to change its registrar for an existing Registered Item (e.g., 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 Item 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 Registered Item 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 RRP, 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 Item 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 Registry Operator 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 and the Eligibility Requirements Dispute Resolution Policy

2) A pending bankruptcy of the Registered Item Holder

3) Dispute over the identity of the Registered Item Holder

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

In all cases, the registrar of record shall respond to the e-mail notice regarding the "transfer" request within five (5) calendar days. Failure to respond will result in a default "approval" of the "transfer." This process is further described in Part 6 - Object Transfers of Appendix C to the Registry Agreement.

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) calendar days.

When the Registry 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 Item Holder shall maintain its own records appropriate to document and prove the initial Registered Item registration date, regardless of the number of registrars with which the Registered Item Holder enters into a contract for registration services.

Effect on Term of Registration.

The completion by Registry Operator of a 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. Such extension shall be subject to a fee, as described in Exhibit F.

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 Registered Item registrations or fewer. If the transfer involves registrations of more than 50,000 Registered Item registrations, Registry Operator will charge the gaining registrar a one-time flat fee of US$ 50,000.

EXHIBIT E

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

1. SETTING UP A NEW ACCOUNT
Registry Operator's procedure for setting up a new Registrar account will consist of three phases; initiation, completion and approval. The tasks within each phase must be completed satisfactorily in order for Registrar to proceed to the next phase. Prior to the initiation phase, upon initial contact with a Registrar interested in working with the Registry Operator, the assigned Account Manager (as described in Exhibit B) will send out an information package that will include all necessary documentation, contracts, forms, and software required by Registrar to complete all necessary phases.

2. SECURITY
Each EPP session shall be authenticated and encrypted using two-way secure socket layer ("SSL") protocol. Registrar agrees to authenticate every RRP client connection with the Registry System using both an X.509 server certificate issued by a commercial Certification Authority identified by Registry Operator and its Registrar password, which it shall disclose only 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.

3. REGISTRAR NOTIFICATION PROCEDURE
Registry Operator shall be responsible for notifying registrars of events that affect the performance of the Registry System. These events may include but will not be limited to; planned downtime, unplanned downtime due to; force majeure (natural disaster), security breach, Denial of Service (DoS) attacks or other such malicious events and other system failure events.
Registry Operator will follow strict guidelines for notifying registrars of any planned downtime. At a minimum all registrars will be made aware of any scheduled downtime in no less than 10 working days prior to the event.
Further, Registry Operator will use all reasonable efforts to alert all affected registrars of any unplanned downtime immediately.

4. REGISTRATION REQUIREMENTS
In addition to the provisions of Subsections 3.3, 3.4 and 3.5 of this Agreement, in its registration agreement with each Registered Name Holder and SLD E-mail Address Holder, Registrar shall require such Registered Name Holder or SLD E-mail Address Holder to:

(a) represent and warrant that the data provided in the registration application is true, correct, up to date and complete;

(b) represent and warrant that the registrant will use best efforts at all times during the term of his or her registration to keep the information provided above up to date;

(c) represent and warrant that the registration satisfies the Eligibility Requirements;

(d) agree to be subject to the Eligibility Requirements Dispute Resolution Policy (the "ERDRP") and the Uniform Domain Name Dispute Resolution Policy (the "UDRP"); and

(e) agree that Registry Operator will have no liability of any kind for any loss or liability resulting from (i) the processing of registration requests prior to live SRS launch, including, without limitation, the ability or inability of registrant to obtain a Registered Name or SLD E-mail Address registration using these processes; or (ii) any dispute over any Registered Name, SLD E-mail Address, Defensive Registration or NameWatch Registration, including the decision of any dispute resolution proceeding related to any of the foregoing.

In addition to the provisions of Subsections 3.3, 3.4 and 3.5 of this Agreement, in its registration agreement with each Defensive Registration Holder, Registrar shall require such Defensive Registration Holder to:

(a) represent and warrant that the data provided in the registration application is true, correct, up to date and complete;

(b) represent and warrant that the registrant will use best efforts at all times during the term of his or her registration to keep the information provided above up to date;

(c) represent and warrant that the registration satisfies the Eligibility Requirements;

(d) agree that the Defensive Registration will be subject to challenge pursuant to the ERDRP;

(e) agree that if the Defensive Registration is successfully challenged pursuant to the ERDRP, the Defensive Registration Holder will pay the challenge fees;

(f) if a challenge is successful, then the Defensive Registration will be subject to the procedures described in the ERDRP and the Eligibility Requirements including, without limitation, the cancellation of the Defensive Registration Holder's Defensive Registrations;

(g) agree that if a Phase I Defensive Registration (as described in Appendices C and L to the Registry Agreement) is successfully challenged on the basis that it did not meet the applicable eligibility requirements, the Defensive Registration Holder will thereafter be required to demonstrate, at its expense, that it meets the eligibility requirements for Phase I Defensive Registrations for all other Phase I Defensive Registrations that it registered within .name through any registrar. In the event that the Defensive Registration Holder is unable to demonstrate the foregoing with respect to any such Phase I Defensive Registration(s), those Defensive Registration(s) will be cancelled; and

(h) agree that Registry Operator will have no liability of any kind for any loss or liability resulting from (i) the processing of registration requests prior to live SRS launch, including, without limitation, the ability or inability of registrant to obtain a Defensive Registration or NameWatch Registration using these processes; or (ii) any dispute over any Registered Name, SLD E-mail Address, Defensive Registration or NameWatch Registration, including the decision of any dispute resolution proceeding related to any of the foregoing.

5. ELIGIBILITY REQUIREMENTS
Registrar shall comply with the provisions of the Eligibility Requirements and the ERDRP as they apply to registrars.

6. START-UP PROCEDURES
Registrar shall comply with all procedures implemented by Registry Operator in connection with the launch of the Registry TLD as described in Appendix J to the Registry Agreement, as may be modified from time to time. Such procedures shall be posted on Registry Operator's world wide web site, located at <http://www.gnr.com>.

7. DISCLAIMERS
Registry Operator will have no liability of any kind for any loss or liability resulting from (a) the processing of registration requests prior to live SRS launch, including, without limitation, the ability or inability of a registrant to obtain a domain name or SLD E-mail address registration using these processes; or (b) any dispute over any Registered Name, SLD E-mail Address, Defensive Registration or NameWatch Registration, including the decision of any dispute resolution proceeding related to any of the foregoing.

---

EXHIBIT F

REGISTRATION FEES

1. Registered Name - Initial Registration Fees
The fee per year that Registry Operator may charge at the time of registration for each Registered Name registered (the "Registered Name Initial Registration Fee") during the Term of the Registry Agreement depends upon the total number of Registered Names registered at that time in the Registry TLD and shall not exceed the fees set forth in the following table:

Maximum Registered Name Initial Registration Fee	Volume Range (Number of Registered Names)
US $5.25	0 to 7,999,999
US $5.00	8,000,000 to 14,999,999
US $4.75	15,000,000 +

The Registered Name Initial Registration Fees above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the Registered Name Initial Registration Fee and any applicable taxes in full at the time of registration.

2. Registered Name - Renewal Fees
The fee per year that Registry Operator may charge at the time of renewal for each Registered Name renewal (the "Registered Name Renewal Fee") in the Registry TLD during the Term of the Registry Agreement will be equivalent to the Registered Name Initial Registration Fee chargeable to Registrar at the time of renewal, and may not exceed the fees described in Subsection 1 above. The Registered Name Renewal Fees referred to above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the Registered Name Renewal Fee and any applicable taxes in full at the time of renewal.

3. Cooperative Marketing Fund Share per Registered Name
Registry Operator will provide a Cooperative Marketing Fund as described in Appendix J to the Registry Agreement. The additional fees chargeable for the service (the "Cooperative Marketing Fund Share") depend upon the total number of Registered Names registered at the time in the Registry TLD, and shall not exceed the fees set forth in the following table:

Cooperative Marketing Fund Share Fee	Volume Range (Number of Registered Names)
US $5.00	0 to 349,999
US $3.00	350,000 to 999,999
US $1.00	1,000,000 to 10,000,000

The Cooperative Marketing Fund Share fees above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the Cooperative Marketing Fund Share fee and any applicable taxes in full at the time of registration.

4. Fee for Intellectual Property NameWatch Service
Registry Operator will provide an intellectual property NameWatch ("NameWatch") service as described in Appendix C to the Registry Agreement. NameWatch reports will be available on a daily, weekly or monthly basis. The fee charged by Registry Operator for NameWatch registration (the "NameWatch Fee") may not exceed the fees set forth in the following table:

Maximum NameWatch Fee	NameWatch Reporting Frequency
US $50.00 per year	Daily
US $50.00 per year	Weekly
US $50.00 per year	Monthly

The NameWatch Fees above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. The ICANN-Accredited Registrar sponsoring the NameWatch registration shall pay the NameWatch Fee and any applicable taxes in full at the time of registration.

5. Second Level Domain Email Forwarding Service - Initial Registration Fees
The SLD E-mail Address forwarding service is described in Appendix C to the Registry Agreement. The fee per year that Registry Operator may charge at the time of registration for each SLD E-mail Address registered (the "SLD E-mail Initial Registration Fee") during the Term of the Registry Agreement depends upon the total number of SLD E-mail Addresses registered at that time in the Registry TLD and shall not exceed the fees set forth in the following table:

Maximum SLD E-mail Initial Registration Fee	Volume Range (Number of Registered SLD E-mail Addresses)
US $20.00	0 to 1,999,999
US $17.00	2,000,000 to 4,999,999
US $15.00	5,000,000 +

The SLD E-mail Initial Registration Fees above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the SLD E-mail Initial Registration Fee and any applicable taxes in full at the time of registration.

6. Second Level Domain Email Forwarding Service-Renewal Fees
The fee per year that Registry Operator may charge at the time of renewal for each SLD E-mail address renewal (the "SLD E-mail Renewal Fee") in the Registry TLD during the Term of the Registry Agreement will be equivalent to the SLD E-mail Initial Registration Fee chargeable at that time and may not exceed the fees described in Subsection 5 above. The SLD E-mail Renewal Fees referred to above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the SLD E-mail Renewal Fee and any applicable taxes in full at the time of renewal.

7. Defensive Registration - Initial Registration Fees
Registry Operator's Defensive Registration Service is described in Appendices C and L to the Registry Agreement. The fees charged by Registry Operator for Defensive Registrations (the "Defensive Registration Fee") may not exceed the fees set forth in the following table:

Per Defensive Registration on a Third Level Only
US $ 250	Per Defensive Registration in Combination (both 2nd and 3rd level)

The Defensive Registration Fees do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the Defensive Registration Fee and any applicable taxes in full at the time of registration.

8. Defensive Registration - Renewal Fees
The fee that Registry Operator may charge for each Defensive Registration renewal (the "Defensive Registration Renewal Fee") in the Registry TLD during the Term of the Registry Agreement will be equivalent to the Defensive Registration Fee chargeable at that time and may not exceed the fees described in Subsection 7 above. The Defensive Registration Renewal Fees referred to above do not include any direct or indirect taxation that Registry Operator may be obligated to add on. Registrar shall pay the Defensive Registration Renewal Fee and any applicable taxes in full at the time of renewal.

9. Multilingual/International Domain Name Registrations
During the Term of the Registry Agreement, Registry Operator contemplates the introduction of Multilingual Domain Name Registrations, offered through ICANN-Accredited Registrars. The charge for this service will be negotiated with ICANN.

10. Bulk Transfer Fee
For a bulk transfer approved by ICANN under Part B of Exhibit D to this Agreement, Registry Operator will charge the gaining registrar US$0 (for transfer of 50,000 combined Registered Items or fewer) or US$50,000 (for transfers of more than 50,000 combined Registered Items). This amount does not include any direct or indirect taxation that Registry Operator may be obligated to add on, the payment of which shall be the Registrar's sole obligation.

11. Fees for Transfers of Sponsorship of Registered Item Registrations
Where the sponsorship of a Registered Item is transferred from one ICANN-Accredited Registrar to another ICANN-Accredited Registrar, Registry Operator will require the registrar receiving the sponsorship to request (a) a renewal of one year, in the case of Registered Name and SLD E-mail Address registrations, or (b) an extension of one year, in the case of Defensive Registrations and NameWatch registrations. In connection with such renewal or extension, Registry Operator will charge a fee for the requested renewal or extension (a "Renewal Fee"), as such fees are set forth in this Exhibit. For extension of Defensive Registrations, the extension fee shall be one-tenth of the then-applicable Defensive Registration Fee. The transfer shall result in an extension according to the renewal request, subject to a ten-year maximum on the future term of any Registered Item. The Renewal Fee and any applicable taxes shall be paid in full at the time of the transfer by the ICANN-Accredited Registrar receiving sponsorship of the Registered Item.

12. Fee Adjustments
The pricing for initial and renewal registrations of Registered Items set forth above shall be adjusted pursuant to Subsections 3.14.5 and 4.4 of the Registry Agreement.

---

EXHIBIT G

SERVICE LEVEL AGREEMENT

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

1.1 "Claim Month" means the calendar month when SRS Unavailability occurred, for which the Registrar can claim SLA Credit.

1.2 "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.3 "Monthly Timeframe" shall mean each single calendar month beginning and ending at 0000 Greenwich Mean Time (GMT).

1.4 "Performance Specifications" refers to a description of the functional attributes of a particular system or service. The attributes outlined in a Performance Specification are measurable.

1.5 "Planned Outage" means the periodic pre-announced occurrences when the SRS Service will be stopped for maintenance or care. Planned Outages will be published at least one week in advance to the Registrar Community in the form on an email to each Registrar and a notice posted on Registry Operator's web site. Planned Outages will be scheduled only during the following window period of time each week, 0600 - 1500 GMT on Sunday (the "Planned Outage Period"). The beginning of 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 4 hours/per calendar week beginning at 1200 GMT Monday nor total more than 8 hours/per month. Notwithstanding the foregoing, Registry Operator may incur one (1) additional Planned Outage of up to 12 hours in duration during the Planned Outage Period and the immediately following three hours for major systems or software upgrades ("Extended Planned Outages"). These Extended Planned Outages represent total allowed Planned Outages for the month.

1.6 "Registrar Community" refers to all ICANN-Accredited Registrars accredited by ICANN for the Registry TLD and who have executed Registry-Registrar Agreements with Registry Operator for the Registry TLD.

1.7 "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 service being tested and back again. Usually measured in milliseconds.

1.8 "SLA" means this Service Level Agreement between Registry Operator and Registrar, as set forth in this Exhibit.

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

1.10 "SRS Service" shall mean the service accessible to Registrar for operating on the main registry data store using the defined protocol (RRP/EPP) for Registry-Registrar interaction. It does not include WWW, FTP, SCP or other services not associated directly with adding, deleting or modifying domain-names.

1.11 "SRS Availability" means when the SRS Service is operational and predictably responding in a commercially reasonable manner. By definition, this does not include Planned Outages or Extended Planned Outages. System Availability will be monitored and recorded by Registry Operator from multiple datapoints within the Internet. The following formula shall be used for calculating SRS Availability:

where:

A = 100 * (	TA - UDT	)
	TA

A = SRS Availability in percent
UDT = Unplanned Downtime in hours for the Monthly Timeframe
TA = Time available in hours for the Monthly Timeframe

1.11.1 The following periods will not be included in calculating SRS Availability:

1.11.1.1 All periods of SRS Unavailability that result from the effects of scheduled service maintenance;

1.11.1.2 All periods of SRS Unavailability that result from events locally at the Registrar, or events outside of Registry Operator's control; and

1.11.1.3 All periods of SRS Unavailability that result from events that can be classified as malicious attacks, such as denial of service ("DOS") attacks.

1.12 "SRS Unavailability" means when, as a result of a failure of systems within Registry Operator's control, Registrar is unable to either:

1.12.1 establish a session with the SRS gateway which shall be defined as:

1.12.1.1 successfully completing a TCP session start;

1.12.1.2 successfully completing the SSL authentication handshake; and

1.12.1.3 successfully completing the registry registrar protocol ("RRP") session command.

1.12.2 Execute a 3 second average round trip for 95% of the RRP check domain commands and/or less than 5 second average round trip for 95% of the RRP add domain commands, from the SRS gateway, through the SRS system, back to the SRS gateway as measured during each Monthly Timeframe.

1.13 "Transaction" shall mean completion of a defined SRS command.

1.14 "Unplanned Downtime" shall mean all of the following:

1.14.1 The amount of time recorded between a trouble ticket first being opened by Registry Operator in response to a Registrar's claim of SRS Unavailability for that Registrar through the time when the Registrar and Registry Operator agree the SRS Unavailability has been resolved with a final fix or a temporary work around, and the trouble ticket has been closed. This will be considered SRS Unavailability only for those Registrars impacted by the outage as evidenced by their submission of an SLA claim;

1.14.2 The amount of time recorded between a trouble ticket first being opened by the Registry Operator in the event SRS Unavailability that affects all of the Registrar Community through the time when the Registry Operator resolves the problem with a final fix or a temporary work around, and the trouble ticket is closed;

1.14.3 The amount of time the Planned Outage exceeds the limits established in Subsection 1.5 above; and

1.14.4 The amount of time that the Planned Outage time occurs outside the window of time established in Subsection 1.5 above.

2. Service Level (Availability and Performance)

2.1 SRS Service. Registry Operator provides built-in redundancy into the SRS Service in the form of 2 databases capable of running the SRS Service. Such redundancy will ensure that SRS Unavailability is kept to an absolute minimum.

2.1.1 SRS Service Availability = 99.4%. Registry Operator will provide the above-referenced SRS Service Availability. Registry Operator will log SRS Unavailability once Registrar reports an occurrence by phone, e-mail or fax as described in the customer support escalation procedures described in Exhibit B. The committed Performance Specification is 99.4% measured on a monthly basis.

2.1.2 Performance Level. Registry Operator will, on average, be capable of processing 40 Transactions per second.

2.1.3 Response Time. The SRS Service will have a worst-case response time of 3 seconds, not including network delays, before it will be considered Unavailable.

3. Measurement
Registry Operator will monitor the SRS Service Level in accordance with the following principles.

3.1 SRS Service/Component Monitoring: The Monitoring Tools used by Registry Operator will be the following:

3.1.1 TIVOLI Management Environment (TME 10). A suite of distributed systems management products, provides management of network computing resources of many different types from a single point. TME 10 products provide a consistent interface to different operating systems and services, and allow administrators to control users, systems and applications from one desktop. The Registry Operator will use TME 10 to manage and monitor applications, computers, networks and backup.

3.1.2 Big Brother. This tool is designed to let system administrators monitor network, application and computer performance in near real-time, from any web browser, anywhere. Big Brother uses a client-server architecture combined with methods, which both push and pull data. Network testing is done by polling all monitored services from a single machine and reporting these results to a central location. The Registry Operator will use Big Brother to monitor network, computer and application status.

3.1.3 The Multi Router Traffic Grapher (MRTG). This is a tool to monitor the traffic load on network-links. MRTG generates HTML pages containing GIF images that provide a LIVE visual representation of this traffic. The Registry Operator will use this tool for additional monitoring of services, computers and applications using SNMP.

3.2 Performance Monitoring: The SRS Service will be sampled and tested as to their performance pursuant to the schedule attached as Exhibit A to Appendix D of the Registry Agreement.

4. Credits

4.1 Calculation of SLA Credit. If SRS Service Availability is less than the specified service level as defined in Subsection 2.1.1, then Registrar is connected to, and actively operating on the SRS Service by adding domains in the Claim Month, Registrar will be entitled to an SLA Credit. The SLA Credit will be calculated in the following way:

C = (N * R *	(S - A)	) * 5%
	100

for S > A, where:

C = Calculated compensation in US dollars
N = Number of new domain name registrations by claiming Registrar during the Claim Month
R = Current Pricing Level for a domain name in US dollars
S = Agreed service level during the Claim Month in percentage
A = Availability of service during the Claim Month in percentage

Example of SLA Credit Calculation:

Registry Operator records a service level exception across a Claim Month of 25 minutes beyond the time periods contemplated by the SLA. Assuming the Claim Month had 30 days, the Claim Month will contain a total of 43,200 minutes. The 25 minute service level exception equates to 25/43,200 = 0.058% downtime. For purposes of this example, the current pricing level is assumed to be $5.25 and the total number of new domain name registrations by the claiming registrar is 50,000. Thus:

N = 50,000
R = $5.25
S = 99.4% (the agreed SRS Availability)
A = 99.342% (99.4% - 0.058%)

C = (50,000 * 5.25*	(99.4 - 99.342)	) * 5%
	100

C = US $7.61

4.1.1 Under no circumstances shall Registry Operator issue SLA Credits when the availability problems are caused by network providers and/or the systems of the individual Registrars.

4.1.2 Registry Operator will not attempt to discern what discount levels were in effect at the time the specific time of the service level exception, but rather use the then-current discount level. All SLA Credit will be paid, including the appropriate discounts and rate levels, according to the then- current rate schedule.

4.2 Submission of Claim for SLA Credit. In order for Registrars to claim SLA Credit, the following procedure must be followed:

4.2.1 Registrar must submit any claims for credits for any particular Claim Month to Registry Operator by fax within 7 days of the end of the Claim Month. Such claims must include the Registrar's calculation of SRS Unavailability.

4.2.2 Credits can only be claimed by Registrars that were connected to and actively operating on the SRS Service by adding domain name registration in the Claim Month.

4.2.3 SLA Credit will only be given for periods of SRS Unavailability that have been reported as outlined in Subsection 5.1 below.

4.3 Validation of Claim. The Registry Operator will confirm the validity of the SLA Credit application as outlined in Subsections 5.2 and 5.3 below.

4.4 Maximum Credits - The total amount of SLA Credit, across all Registrars, issued by Registry Operator in a Claim Month shall not exceed 5% of Registry Operator's previous Monthly Timeframe's revenue from domain name registrations eligible for SLA Credit. The total amount of SLA Credit, across all Registrars, issued by Registry Operator in a given calendar quarter shall not exceed 5% of the previous calendar quarter's revenue as generated by domain name registrations eligible for a SLA Credit. For purposes of this SLA, Cooperative Marketing Fund Contributions do not constitute revenue.

4.5 Payment of Credits - SLA Credits claimed and validated, as outlined in Subsections 4.1 and 4.3 above, will be given to Registrar by applying them to the Registrar's prepaid account if such account exists. If no such prepaid account exists, then the SLA Credits shall issue as otherwise agreed between the parties and in accordance with Subsection 5.9 below.

4.6 Appeal of Credits - If Registrar has a dispute with regards to the accuracy of the payment of SLA Credit, as outlined in Subsection 4.1, the following procedures will apply:

4.6.1 Registrar may, within 7 days of the Registry Operator validating the claim, send in a request for a review of the calculation. Such request must clearly state the reason for the request.

4.6.2 The request will be assessed and returned with a response within 7 business days.

4.6.3 If the calculation is not revised to the satisfaction of Registrar, Registrar may request that the matter be referred to Registry Operator's Compliance Manager. The Compliance Manager will then use reasonable efforts to establish Registrar's grounds for the complaint.

5. Obligations

5.1 The affected Registrar must assist the Registry Operator by reporting each occurrence of alleged SRS Unavailability to Registry Operator customer service help desk in the manner required by Registry Operator in order for an occurrence to be treated as SRS Unavailability for purposes of the SLA. Registry Operator will treat all SRS Unavailability problems equally and fix them within a commercially reasonable period of time, however, Registry Operator reserves the right to prioritize the order according to problem severity. Incidents flagged by the Monitoring Tools described in Subsection 3 will also be qualified as ticketed events and will be logged for validation purposes.

5.2 In the event that all of the Registrar Community are affected by SRS Unavailability, Registry Operator is responsible for opening a blanket trouble ticket and using commercially reasonable efforts to notify the Registrars of the trouble ticket number and details.

5.3 Both Registrars and Registry Operator must use commercially reasonable good faith efforts to establish the cause of any SRS Unavailability. If it is mutually determined to be a Registry Operator problem, the incident will become part of the Unplanned Outage Time.

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

5.5 Registrar must inform Registry Operator any time its estimated volume of transactions (excluding check domain commands), will exceed its previous month's volume by more than 25%. In the event that Registrar fails to inform Registry Operator of a forecasted increase of volume of transactions of 25% or more and 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 Credit in that Monthly Timeframe. Registrars shall provide their forecasts at least 30 days prior to the first day of the next applicable month. In addition, Registry Operator agrees to provide Registrars with monthly transaction summary reports starting no later than 120 days after the Commencement-of-Service Date.

5.6 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 commercially reasonable and good faith efforts to maintain an accurate 30 day advance schedule of possible upcoming Planned Outages.

5.7 Registry Operator will use commercially reasonable efforts to restore the critical systems of the SRS Service within 48 hours in the event of a Force Majeure and will use commercially reasonable efforts to restore full SRS Service functionality within 72 hours. Outages due to a Force Majeure will not be considered as SRS Unavailability.

5.8 Beginning no later than 120 days after the Commencement-of-Service Date, the Registry Operator will publish preliminary weekly SRS Service 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.9 The SLA will be reconciled, and SLA Credits will be issued, on a quarterly basis.

5.10 The Registrar Community, as a group, may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying service level performance and availability. The frequency of these audits will be no more than once every six month period during the term of this Agreement.

5.11 Registry Operator's obligations under this SLA are waived during the first 120 days after the Live SRS Launch as described in Appendix J to the Registry Agreement.

5.12 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. Registry Operator will notify Registrar regarding any scheduled maintenance and unavailability of the TLD root-servers. Registry Operator will use reasonable efforts to notify Registrar in advance when changes to the schedule occur.

5.13 Registry Operator will provide SRS Availability percentages during each Monthly Timeframe as listed in Subsection 2.

5.14 Registry Operator will update the Whois Service pursuant to the procedures and timelines described in Appendices C, D and O of the Registry Agreement. Registry Operator will notify Registrar in advance when changes to the Whois Service update schedule occur.

6. Miscellaneous

6.1 This Appendix 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.