Proposed Unsponsored TLD Agreement: Appendix F (.biz) Posted: 27 April 2001

This Registry-Registrar Agreement (the "Agreement") is between NeuLevel, Inc., a Delaware limited liability company, with its principal place of business located at Loudoun Tech Center, 45980 Center Oak Plaza, Sterling, VA 20166 ("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 .biz top-level domain;

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

WHEREAS, Registrar wishes to act as a registrar for domain names within the .biz 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 XRP, with the Registry System.

1.2. "Confidential Information" means all information and materials, including, without limitation, computer software, data, information, databases, protocols, reference implementation and documentation, 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 within 15 days of the disclosure.

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

1.4. The "Effective Date" shall be the date on which it 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 Kits" shall mean the Tool Kits set forth in Exhibit A. The Registrar Tool Kits shall be comprised of the Domain Name Application Service and the Registry Live Tool Kits.

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 TLD" means the .biz TLD.

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

1.13. "Registry 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 registrar system operated by Registry Operator for Registered Names in the Registry TLD.

1.15. "Term" means the term of this Agreement, as set forth in Subsection 8.1.

1.16. "XRP" means the extensible registry-registrar protocol used by the Registry System.

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 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 Kits; License.

2.3.1. Domain Name Application Service Tool Kit. Until the expiration of the Domain Name Application Service (as set forth in Appendix J to the Registry Agreement), Registry Operator shall provide to Registrar a copy of the Domain Name Application Service Tool Kit no later than five business days after the Effective Date. Such Domain Name Application Service Tool Kit shall provide sufficient technical specifications to allow Registrar to interface with the Domain Name Application Service portion of the Registry System and employ its features that are available to Registrars; provided that if the Effective Date occurs prior to the date that Registry Operator has made the Domain Name Application Service Tool Kit available to .biz accredited Registrars generally ("DNAS Availability Data"), and such date is prior to the expiration of the Domain Name Application Service, Registry Operator shall provide to Registrar a copy of the Domain Name Application Service Tool Kit, no later than five (5) business days after the DNAS Availability Date.

2.3.2. Registry Live Tool Kit. No later than five business days after the Effective Date, Registry Operator shall provide to Registrar a copy of the Registry Live Tool Kit, which shall provide sufficient technical specifications to allow Registrar to interface with the Registry Live portion of the Registry System and employ its features that are available to Registrars; provided that if the Effective Date occurs prior to the date that Registry Operator has made the Registry Live Tool Kit available to .biz accredited Registrars generally ("Live Availability Data"), Registry Operator shall provide to Registrar a copy of the Registry Live Tool Kit, no later than five (5) business days after the Live Availability Date.

2.3.3. License. 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 the XRP, APIs and any reference client software included in the Registrar Tool Kits, as well as updates and redesigns thereof, for providing 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 XRP, APIs, or other software licensed hereunder that will 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 XRP, 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 Registrars is collected, the intended recipients (or categories of recipients) of such Personal Data, the mechanism for access to and correction of such Personal Data, and the retention policy of Registry Operator for 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. ICANN Requirements. Registry Operator's obligations hereunder are subject to modification at any time as a result of ICANN-mandated requirements and consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by ICANN.

3. OBLIGATIONS OF REGISTRAR

3.1. Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full force and effect its accreditation by ICANN as a registrar for the Registry TLD, by either, at the sole discretion of ICANN, amending its existing ICANN Accreditation Agreement with ICANN ("Accreditation Agreement") to apply to Registry Operator, or by signing a new Accreditation Agreement with ICANN that applies to Registry Operator.

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

3.3. Registrar's Registration Agreement. At all times while it is sponsoring the registration of any Registered Name within the Registry System, Registrar shall have in effect an electronic or paper registration agreement with the Registered Name Holder. The initial form of Registrar's registration agreement is attached as Exhibit C (which may contain multiple alternative forms of the registration agreement). Registrar may from time to time amend those forms of registration agreement or add alternative forms of registration agreement, provided a copy of the amended or alternative registration agreement is furnished to the Registry Operator three business 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 this indemnification obligation survive the termination or expiration of the registration agreement.

3.5. 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.6. Security. Registrar agrees to 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. All data exchanged between Registrar's system and the Registry System shall be protected to avoid unintended disclosure of information. Registrar agrees to employ the necessary measures to prevent its access to the Registry System granted hereunder from being used to (1) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than your own existing customers; or (2) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator, any other registry operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations. In addition, Registry Operator may require other reasonable security provisions to ensure that the Registry System is secure.

3.7. Resolution of Technical Problems. Registrar agrees to 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 XRP and the APIs in conjunction with Registrar's systems. Registrar agrees that in the event of significant degradation of the System or other emergency, Registry Operator may, in its sole discretion, temporarily suspend access to the 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.8. Time. Registrar agrees that 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.9. 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.10. 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.10.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.

3.10.2. operational standards, policies, procedures, and practices for the Registry TLD as set forth in the Registry Agreement and as 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.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. As one element of the Fees, Registrar agrees to pay Registry Operator the applicable variable fees assessed to Registry Operator by ICANN under, as permitted by Subsection 3.14.5 of the Registry Agreement.

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 so long as payment is assured. All Fees are due immediately upon receipt of applications for initial and renewal registrations, or upon provision of other services provided by Registry Operator to Registrar. Payment shall be made via debit or draw down of the deposit account, letter of credit or other credit facility. Registry Operator shall provide monthly invoices to the Registrar.

4.3. Non-Payment of Fees. In the event Registrar has insufficient funds deposited or available through the letter of credit or credit facility with Registry Operator, Registry Operator may do any or all of the following: (a) stop accepting new initial or renewal registrations from Registrar; (b) delete the domain names associated with any negative balance incurred from the Registry database; and (c) 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 (a) Registry Operator pays ICANN Variable Registry-Level Fees for the Registry TLD; (b) Registrar is not required to pay ICANN an on-going component of registrar accreditation fees for accreditation as a registrar in the Registry TLD; (c) 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 (d) 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 be required to 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 (a) is disclosed with the Disclosing Party's prior written approval; or (b) is or has entered the public domain through no fault of the Receiving Party; or (c) is known by the Receiving Party prior to the time of disclosure; or (d) is independently developed by the Receiving Party without use of the Confidential Information; or (e) is made generally available by the Disclosing Party without restriction on disclosure.

5.1.7. In the event the Receiving Party is required by law, regulation or court order to disclose any of Disclosing Party's Confidential Information, Receiving Party will promptly notify Disclosing Party in writing prior to making any such disclosure in order to facilitate Disclosing Party seeking a protective order or other appropriate remedy from the proper authority, at the Disclosing Party's expense. Receiving Party agrees to cooperate with Disclosing Party in seeking such order or other remedy. Receiving Party further agrees that if Disclosing Party is not successful in precluding the requesting legal body from requiring the disclosure of the Confidential Information, it will furnish only that portion of the Confidential Information which is legally required.

5.1.8. The Receiving Party's duties under this Subsection 5.1 shall expire five (5) years after the information is received or earlier, upon written agreement of the parties.

5.2. Intellectual Property.

5.2.1. Subject to Subsection 3.5, 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. In addition, Registry Operator, or its suppliers and/or licensees, shall own all right, title and interest in and to the XRP, APIs, Registrar Tool Kits, and any software incorporated into the Registry System, as well as all intellectual property appurtenant thereto.

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 of 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; provided, however, that in any such case: (a) Registry Operator provides Registrar with prompt notice of any such claim, and (b) 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. Limitation of Liability. EXCEPT AS PROVIDED IN SUBSECTION 6.3 BELOW, IN NO EVENT SHALL EITHER PARTY BE LIABLE FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES FOR ANY VIOLATIONS OF THIS AGREEMENT.

6.3. Performance Credits. In the event Registry Operator fails to meet the performance specifications set forth in Exhibit G of this Agreement, Registry Operator shall provide a credit to Registrar in an amount equal to its proportionate share of applicable performance credits set forth in Exhibit H to this Agreement. Such performance credits shall constitute the sole and exclusive remedy available to Registrar with regard to Registry Operator's failure to meet the performance specifications.

7. DISPUTE RESOLUTION

7.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 Commonwealth of Virginia, USA. There shall be three arbitrators: each party shall choose one arbitrator and, if the two arbitrators are not able to agree on a third arbitrator, the third shall be chosen by the ICC. The parties shall bear the costs of the arbitration in equal shares, subject to the right of the arbitrators to reallocate the costs in their award as provided in the ICC rules. The parties shall bear their own attorneys' fees in connection with the arbitration, and the arbitrators may not reallocate the attorneys' fees in conjunction with their award. The arbitrators shall render their decision within ninety days of the initiation of arbitration. Any litigation brought to enforce an arbitration award shall be brought in a Commonwealth or federal court in the eastern district of the Commonwealth of Virginia, USA; however, the parties shall also have the right to enforce a judgment of such a court in any court of competent jurisdiction. For the purpose of aiding the arbitration and/or preserving the rights of a Party during the pendency of an arbitration, each Party shall have the right to seek temporary or preliminary injunctive relief from the arbitration panel or a court located in eastern district of the Commonwealth of Virginia, USA, which shall not be a waiver of this arbitration agreement.

8. TERM AND TERMINATION

8.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 expiration of the Registry Agreement. 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.

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

8.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.

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

8.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.

8.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 9.1.1.

8.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.

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

8.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.

8.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.

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

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

8.4. Survival. In the event of termination of this Agreement, the following shall survive: Subsections 2.6, 3.5, 5.1, 5.2, 6.1, 6.2, 7.1, 8.3.3, 8.3.4, 8.4, 9.2, 9.3.3, 9.5, 9.6, 9.8, 9.9, 9.10, 9.11 and 9.13 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.

9. MISCELLANEOUS

9.1. Assignments.

9.1.1. Assignment to Successor Registry Operator. In the event the Registry Operator's Registry Agreement is terminated (and such termination is deemed final under the Registry Agreement) 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.

9.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.

9.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.

9.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 copy to:

If to Registry Operator:

NeuLevel, Inc.
Loundoun Tech Center
45980 Center Oak Plaza
Sterling, VA 20166
Attn: VP of Policy and Insdustry Relations

with a copy to:

NeuLevel, Inc.
Loundoun Tech Center
45980 Center Oak Plaza
Sterling, VA 20166
Attn: General Counsel

9.3. Representations and Warranties.

9.3.1. Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the law of the ______________, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) it is, and during the Term of this Agreement will continue to be, accredited by ICANN or its successor, (4) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, (5) 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.

9.3.2. Registry Operator. Registry Operator represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the laws of the State of Delaware, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) the execution, performance and delivery of this Agreement has been duly authorized by Registry Operator, and (4) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registry Operator in order for it to enter into and perform its obligations under this Agreement.

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

9.4. Insurance. During the Term of this Agreement, and any renewal Terms, Registrar shall have in place US $1,000,000 in comprehensive legal liability insurance from a reputable insurance provider with an A.M. Best rating of "A" or better. Such Insurance shall be used to indemnify and hold harmless Registry Operator and its employees, directors, officers, representatives, agents and affiliates from all costs and damages (including reasonable attorneys' fees) which it may suffer by reason of Registrar's failure to indemnify Registry Operator as provided above. Registrar shall provide a copy of the insurance policy to Registry Operator upon Registry Operator's reasonable request.

9.5. 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 acknowledges that nothing in this Agreement shall confer upon Registrar the status of an intended third-party beneficiary to the Registry Agreement.

9.6. 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.

9.7. 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, equipment or facilities shortages which are being experienced by providers of telecommunications services generally, or other similar force beyond such Party's reasonable control, 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.

9.8. Amendments. Except as otherwise provided herein, no amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties.

9.9. 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.

9.10. Attorneys' Fees. If any legal action or other legal proceeding (including arbitration) relating to the performance under this Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys' fees, costs and disbursements (in addition to any other relief to which the prevailing Party may be entitled).

9.11. Construction. The Parties agree that any rule of construction to the effect that ambiguities are to be resolved against the drafting party shall not be applied in the construction or interpretation of this Agreement.

9.12. Further Assurances. Each party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and other documents, and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement.

9.13. 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.

NeuLevel, Inc. By: Name: Title:

[Registrar] By: Name: Title:

Registry-Registrar Software Development Kit includes:

1. Software Development Kit for Domain Name Application Service

• Secure ftp client
• Reference client implementation:
• TCL
• Interface definition:
• ABNF
• XML schema
• Registry Operational Profile (our extensions)
• Authentication and Encryption guidelines

2. Software Development Kit for Registry Live

• Reference client implementations:
  • Java
  • Language bindings
  • Interface Definition Language (IDL)
• Interface definition:
  • ABNF
  • XML schema
• Registry Operational Profile (our extensions)
• Authentication and Encryption guidelines
• Epp "feature freeze" drafts
• Epp test plan and coverage matrix
• Java, API documentation
  
  

  ---

During the Term of this Agreement, Registry Operator will provide reasonable telephone and electronic customer support to Registrar, not Registered Name holders or prospective customers of Registrar, for non-technical issues solely relating to the Registry System and its operation. Registry Operator will provide Registrar with a telephone number and e-mail address for such support during implementation of the XRP, APIs and Software. While e-mail and FAQs are the primary method of help, Registry Operator will provide support will be available on a 7-day/24-hour basis. Registry Operator will provide a web-based customer service capability in the future and such web-based support will become the primary method of customer service support to Registrar at such time.

The Registry Operator provides a clear, concise and efficient deliberation of customer support responsibilities. Registrars provide support to registrants and registries provide support for Registrars. This allows the Registry to focus its support on the highly technical and administratively complex issues that arise between the Registry and the Registrar.

Technical Help Systems

NeuLevel will provide the Registrars with the following types of technical support:

• Web-based self-help services, including:
  • Knowledge bases
  • Frequently asked questions
  • White papers
  • Downloads of XRP client software
  • Support for email messaging
• Telephone support from our central Help Desk
• Fee-based consulting services.

Web Portal

Registry Operator will implement a secure Web-based multimedia portal to help support registrar operations. To obtain access to our Web-based services, a registrar must register his registrants with us, and must have implemented our security features, including SSL encryption, log in with user ID and password, and digital certificates for authentication. The home page of the web portal will include a notice to registrars of planned outages for database maintenance or installation of software upgrades. This notification will be posted 30 days prior to the event in addition to active notification including phone calls and email. We will also record outage notifications in the help desk database to facilitate compliance with the service-level agreement. Finally, seven days and again two days prior to the scheduled event, we will use both an email and a Web-based notification to remind registrars of the outage.

Non-affiliated registrars and the general Internet community may obtain generic information from NeuLevel's public Web site, which will describe our TLD service offerings and list ICANN-certified registrars providing domain-name services.

Central Help Desk

In addition to implementing the Web site, we will provide telephone support to our registrars through our central Help Desk. Access to the help desk telephone support is through an automatic call distributor that routes each call to the next available customer support specialist. We will authenticate callers by using caller ID and by requesting a pre-established pass phrase that is different for each registrar. Requests for assistance may also come to the Help Desk via email, either directly or via the secure Web site. The Help Desk's three tiers of support are:

Tier-1 Support. Telephone support to registrars who normally are calling for help with customer domain-name problems and such other issues such as XRP implementation or billing and collection. Problems that can't be resolved at Tier 1 are escalated to Tier 2.

Tier-2 Support. Support provided by members of the technical support team, who are functional experts in all aspects of domain-name registration. In addition to resolving escalated Tier 1 problems with XRP implementation and billing and collection, Tier 2 staff provides technical support in system tuning and workload processing.

Tier 3 Support. Complex problem resolution provided by on-site maintenance technicians, third party systems and software experts, and vendors, depending on the nature of the problem.

In turn, the Help Desk uses an automated software package to collect call statistics and record service requests and trouble tickets in a help desk database. The help desk database documents the status of requests and tickets, and notifies the Help Desk when an SLA threshold is close to being breached. Each customer-support and technical support specialist uses our problem management process to respond trouble tickets with a troubleshooting, diagnosis, and resolution procedure and a root-cause analysis.

Escalation Policy

Our escalation policy defines procedures and timelines for elevating problems either to functional experts or to management for resolution if they not resolved within the escalation-policy time limits. The following table is an overview of our escalation policy.

Level	Description	Escalation Policy	Notification
I	Catastrophic outage affecting overall registry operations	Data-center manager escalates to NeuLevel management and Disaster-Recovery Team if not resolved in 15 minutes	Web portal and e-mail notifications to all Registrars within 15 minutes; updates every 30 minutes
II	Systems outage affecting one or two registrar sessions but not the entire system	Systems engineer escalates to data-center manager if not resolved in one hour	Web-portal notification to all registrars; hourly updates
III	Technical questions	Help Desk customer-support specialist escalates to the systems engineer if not resolved in two hours	Hourly updates to registrar via e-mail
IV	Basic questions	Help Desk customer-support specialist escalates to the systems engineer if not resolved within four hours	Hourly updates to registrar via e-mail

Staffing

Initially, Registry Operator will staff its Help Desk with a complement of customer service specialists. We will add staff as necessary to respond to incoming requests within the service-level agreement. Customer-service specialists will obtain assistance from Registry Operator's technical staff for any problems that cannot be resolved in one phone call.

Test and Evaluation Facility

Registry Operator will establish an operational test-and-evaluation facility that will be available for Registrars to test their client XRP system. Our technical-support team, which consists of functional experts in the processes and technologies for domain-name registration, will support the registrars' testing.

Once each new Registrar is satisfied that its system is compatible with the registry system, it will schedule a formal acceptance test that will be monitored by our system engineer. After a registrar has passed the acceptance test, we will issue its user id, passwords, and digital certificates, and the Registrar can begin operations.

Customer Satisfaction Survey

To determine Registrars' satisfaction with registry services, Registry Operator will implement a Web-based customer-satisfaction survey that will consist of a set of survey questions with responses ranging from one to five on the Likert Scale. We will tabulate the results and publish them on the Web site.

To further verify the quality of our customer services, Registry Operator will commission a biannual customer-satisfaction survey by an independent third party.

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 an 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 XRP, 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 electronic 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 electronic 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 electronic 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; provided that the data to be transferred to Registry Operator is in the form specified by Registry Operator as may be reasonably approved by ICANN ("Approved Format"). If the transfer involves registrations of more than 50,000 names, and the data to be transferred to Registry Operator is in
the Approved Format, Registry Operator will charge the gaining registrar a one-time flat fee of US$ 50,000. If the data to be transferred is not in the Approved Format, the Registry Operator may charge a reasonable fee in connection with the costs associated with reformating such data.

I. Registration Requirements

Before the Registry Operator will accept applications for registration from Registrar, all domain name applicants in the .biz TLD ("Applicants") must:

1. Enter into an electronic or paper registration agreement with the Registrar ("Registrar"), in accordance with the ICANN Registrar Accreditation Agreement ("Accreditation Agreement") and this Agreement. Such electronic or paper registration agreement shall include, at a minimum, the following certifications:

a) The data provided in the domain name registration application is true, correct, up to date and complete; and

b) The registrant will keep the information provided above up to date.

2. Certify in the Registration Agreement that to the best of its knowledge:

a) The registered domain name will be used primarily for bona fide business or commercial purposes and not (i) exclusively for personal use; or (ii) solely for the purposes of (1) selling, trading or leasing the domain name for compensation, or (2) the unsolicited offering to sell, trade or lease the
domain name for compensation.

b) The domain name registrant has the authority to enter into the registration agreement; and

c) The registered domain name is reasonably related to the registrant's business or intended commercial purpose at the time of registration.

II. Incorporation of .Biz Dispute Resolution Services

In addition, Registrar agrees to incorporate the following text (or translation of such text into relevant language) into their Registration Agreement:

"The Registrant acknowledges having read and understood and agrees to be bound by the terms and conditions of the following documents, as they may be amended from time to time, which are hereby incorporated and made an integral part of this Agreement:

(i) The Uniform Domain Name Dispute Resolution Policy, available at <URL>;

(ii) The Start-up Dispute Resolution Policy ("SUDRP"), available at <URL>; and

(iii) The Restrictions Dispute Resolution Criteria and Rules, available at <URL>."

The SUDRP sets forth the terms and conditions in connection with a dispute between a registrant of a .biz domain name ("Registrant") with any third party (other than Registry Operator or Registrar) over the registration or use of a .biz domain name registered by Registrant that is subject to the Start-up Intellectual Property Notification Service ("SIPNS"). SIPNS is a service introduced by Registry Operator to notify a trademark or service mark holder ("Claimant") that a second-level domain name has been registered in which that Claimant claims intellectual property rights. In accordance with the SUDRP and its associated Rules, those Claimants will have the right to challenge registrations through independent ICANN-accredited dispute resolution providers.

The UDRP sets forth the terms and conditions in connection with a dispute between a Registrant and any party other than the Registry Operator or Registrar over the registration and use of an Internet domain name registered by Registrant.

The RDRP sets forth the terms under which any allegation that a domain name is not used primarily for business or commercial purposes shall be enforced on a case-by-case, fact specific basis by an independent ICANN-accredited dispute provider. None of the violations of the Restrictions will be enforced directly by or through Registry Operator. Registry Operator will not review, monitor, or otherwise verify that any particular domain name is being used primarily for business or commercial purposes or that a domain name is being used in compliance with the SUDRP or UDRP processes.

III. Reservation

Registry Operator reserves the right to deny, cancel or transfer any registration that it deems necessary, in its discretion; (1) to protect the integrity and stability of the registry; (2) to comply with any applicable laws, government rules or requirements, requests of law enforcement, in compliance with any dispute resolution process; (3) to avoid any liability, civil or criminal, on the part of Registry Operator, as well as its affiliates, subsidiaries, officers, directors, and employees; (4) for violations of this Agreement and its Exhibits; or (5) to correct mistakes made by Registry Operator or any Registrar in connection with a domain name registration. Registry Operator also reserves the right to freeze a domain name during resolution of a dispute.

• Domain Name Application Fees (Phase 1). Registrar agrees to pay the non-refundable amounts as set forth below:

US $2.00 Per Domain Name Application Submission

• Initial Registration. Registrar agrees to pay the non-refundable amounts as set forth below:
  
  

  Initial Registration Fee (Per Domain Name)	Volume Range (Number of Registered Names)
  US $5.30	0 to 4,999,999
  US $5.00	5,000,000 to 9,999,999
  US $4.75	10,000,000 +

  
  
• Renewal Fees. Registrar agrees to pay the non-refundable amounts as set forth below:
  
  

  Renewal Fee (Per Domain Name)	Volume Range (Number of Registered Names)
  US $5.30	0 to 4,999,999
  US $5.00	5,000,000 to 9,999,999
  US $4.75	10,000,000 +

  
  
• Secure Domain Name Registration Service. Registrar agrees to pay the non-refundable amounts as set forth below:

US $500.00 Per Secure Domain Name Registration

• Fees for Transfers of Sponsorship of Domain-Name Registrations

Where the sponsorship of a domain name is transferred from an ICANN-Accredited Registrar to another ICANN-Accredited Registrar, other than an ICANN approved bulk transfer, Registry Operator may require the registrar receiving the sponsorship to request a renewal of one year for the name. In connection with that extension, Registry Operator may charge a Renewal Fee for the requested extension as provided in the renewal schedule set forth 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.

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

• Enhanced Whois Service. Registrar agrees to pay the non-refundable amounts as set forth below:
  
  To be provided with at least 30 days advance notice: Yearly Subscription Fee Rate, One time Usage Fee

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.

1. Introduction. The attached Performance Specification Matrix ("Matrix") provides a list of performance specifications as they apply to the three Core Services provided by the Registry–SRS, Nameserver, and Whois services.

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

2.1 "Core Services" refers to the three core services provided by the Registry–SRS, Nameserver, and Whois Services.

2.2 "Performance Specification" refers to the specific committed performance service levels as specified herein.

2.3 "Performance Specification Priority" refers to the Registry's rating system for Performance Specifications. Some Performance Specifications are more critical to the operations of the Registry than others. Each of the Performance Specifications is rated as C1-mission critical, C2-mission important, C3-mission beneficial, or C4-mission maintenance.

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

2.5 "SRS" refers to the Shared Registration System; the service that the Registry provides to the Registrar Community. Specifically, it refers to the ability of Registrars to add, modify, and delete information associated with domain names, nameserver, contacts, and registrar profile information. This service is provided by systems and software maintained in coactive redundant data centers. The service is available to approved Registrars via an Internet connection.

2.6 "Nameserver" refers to the nameserver function of the Registry and the nameservers that resolve DNS queries from Internet users. This service is performed by multiple nameserver sites that host DNS resource records. The customers of the nameserver service are users of the Internet. The nameservers receive a DNS query, resolve it to the appropriate address, and provide a response.

2.7 "Service Level Measurement Period" refers to the period of time for which a Performance Specification is measured. Monthly periods are based on calendar months, quarterly periods are based on calendar quarters, and annual periods are based on calendar years.

2.8 "Whois" refers to the Registry's Whois service. The Registry will provide contact information related to registered domain names and nameserver through a Whois service. Any person with access to the Internet can query the Registry's Whois service directly (via the Registry website) or through a Registrar.

3. Performance Specifications. Registry Operator shall use commercially reasonable efforts to provide Registry Services for the Registry TLD. The Performance Specifications defined below establish the basis for the Service Level Exception Credits ("SLE Credits") provided for in Exhibit H to this Registry-Registrar Agreement.

3.1 Service Availability. Service Availability is defined as the time, in minutes, that the Registry's Core Services are responding to its users. Service is unavailable when a service listed in the Matrix is unavailable to all users, that is, when no user can initiate a session with or receive a response from the Registry ("Unavailability"). Service Availability is a C1 priority level.

3.1.1 Service Availability is measured as follows:

Service Availability % = {[(TM - POM) - UOM] / (TM - POM)}*100 where:

TM = Total Minutes in the Service Level Measurement Period (#days*24 hours*60 minutes).

POM = Planned Outage Minutes (sum of (i) Planned Outages and (ii) Extended Planned Outages during the Service Level Measurement Period).

UOM = Unplanned Outage Minutes (Difference between the total number of minutes of Unavailability during the Service Level Measurement Period minus POM).

Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party (to be selected by Registry Operator with the consent of the Registrar(s) to perform an independent calculation of the UOM). The frequency of this audit will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar.

This calculation is performed and the results reported for each calendar month for SRS and Whois availability and for each calendar year for Nameserver availability. Results will be reported to the Registrar Community via e-mail.

3.1.2 Service Availability–SRS = 99.9% per calendar month. Service Availability as it applies to the SRS refers to the ability of the SRS to respond to Registrars that access and use the SRS through the XRP protocol defined in Appendix C of the Registry Agreement. SRS Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for SRS is 99.9% and the Service Level Measurement Period is monthly.

3.1.3 Service Availability–Nameserver = 99.999% per calendar year. Service Availability as it applies to the Nameserver refers to the ability of the Nameserver to resolve a DNS query from an Internet user. Nameserver Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Nameserver is 99.999% and the Service Level Measurement Period is annually.

3.1.4 Service Availability–Whois = 99.95% per calendar month. Service Availability as it applies to Whois refers to the ability of all users to access and use the Registry's Whois service. Whois Unavailability will be logged with the Registry Operator as Unplanned Outage Minutes. The committed Service Availability for Whois is 99.95% and the Service Level Measurement Period is monthly.

3.2 Planned Outage. High volume data centers like the Registry require downtime for regular maintenance. Allowing for regular maintenance ("Planned Outage") ensures a high level of service for the Registry. Planned Outage Performance Specifications are a C4 priority level.

3.2.1 Planned Outage Duration. The Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry Operator is allowed to take the Registry Services out of service for regular maintenance. Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. This Performance Specification, where applicable, has a monthly Service Level Measurement Period. The Planned Outage Duration for the Core Services is as follows:

3.2.1.1 Planned Outage Duration–SRS = 8 hours (480 minutes) per month;

3.2.1.2 Planned Outage Duration–Nameserver = (no planned outages allowed); and

3.2.1.3 Planned Outage Duration–Whois = 8 hours (480 minutes) per month.

3.2.2 Planned Outage Timeframe. The Planned Outage Timeframe defines the hours and days in which the Planned Outage can occur. The Planned Outage Timeframe for the Core Services is as follows:

3.2.2.1 Planned Outage Timeframe–SRS = 0600-1400 UTC Sunday;

3.2.2.2 Planned Outage Timeframe–Nameserver =(no planned outages allowed); and

3.2.2.3 Planned Outage Timeframe–Whois = 0600-1400 UTC Sunday.

3.2.3 Planned Outage Notification. The Registry Operator must notify all of its Registrars of any Planned Outage. The Planned Outage Notification Performance Specification defines the number of days prior to a Planned Outage that the Registry Operator must notify its Registrars. The Planned Outage Notification for the Core Services is as follows:

3.2.3.1 Planned Outage Timeframe–SRS = 3 days;

3.2.3.2 Planned Outage Timeframe–Nameserver =(no planned outages allowed); and

3.2.3.3 Planned Outage Timeframe–Whois = 3 days.

3.3 Extended Planned Outage. In some cases such as software upgrades and platform replacements an extended maintenance timeframe is required. Extended Planned Outages will be less frequent than regular Planned Outages but their duration will be longer. Extended Planned Outage Performance Specifications are a C4 priority level.

3.3.1 Extended Planned Outage Duration. The Extended Planned Outage Duration defines the maximum allowable time, in hours and minutes, that the Registry is allowed to take the Registry Services out of service for extended maintenance. Extended Planned Outages are planned in advance and the Registrar Community is provided warning ahead of time. Extended Planned Outage periods are in addition to any Planned Outages during any Service Level Measurement Period. This Performance Specification, where applicable, has a Service Level Measurement Period based on a calendar quarter. The Extended Planned Outage Duration for the Core Services is as follows:

3.3.1.1 Extended Planned Outage Duration–SRS = 18 hours (1080 minutes) per calendar quarter;

3.3.1.2 Extended Planned Outage Duration–Nameserver =(no planned outages allowed); and

3.3.1.3 Extended Planned Outage Duration–Whois = 18 hours (1080 minutes) per calendar quarter.

3.3.2 Extended Planned Outage Timeframe. The Extended Planned Outage Timeframe defines the hours and days in which the Extended Planned Outage can occur. The Extended Planned Outage Timeframe for the Core Services is as follows:

3.3.2.1 Extended Planned Outage Timeframe–SRS = 0600-1400 UTC Saturday or Sunday;

3.3.2.2 Extended Planned Outage Timeframe–Nameserver =(no planned outages allowed); and

3.3.2.3 Extended Planned Outage Timeframe–Whois = 0600-1400 UTC Saturday or Sunday.

3.3.3 Extended Planned Outage Notification. The Registry must notify all of its Registrars of any Extended Planned Outage. The Extended Planned Outage Notification Performance Specification defines the number of days prior to an Extended Planned Outage that the Registry Operator must notify its Registrars. The Extended Planned Outage Notification for the Core Services is as follows:

3.3.3.1 Extended Planned Outage Timeframe–SRS = 4 weeks;

3.3.3.2 Extended Planned Outage Timeframe–Nameserver =(no planned outages allowed); and

3.3.3.3 Extended Planned Outage Timeframe–Whois = 4 weeks.

3.4 Processing Time. Processing Time is an important measurement of transaction-based services like the Registry. The first three Performance Specifications, Service Availability, Planned Outages and Extended Planned Outages, measure the amount of time that the service is available to its users. Processing Time measures the quality of that service.

Processing Time refers to the time that the Registry Operator receives a request and sends a response to that request. Since each of the Registry Services has a unique function the Performance Specifications for Processing Time are unique to each of the Registry Services. For example, a Performance Specification for the Nameserver is not applicable to the SRS and Whois, etc. Processing Time Performance Specifications are a C2 priority level.

Processing Time Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis. The Registry Operator will log the processing time for all of the related transactions, measured from the time it receives the request to the time that it returns a response.

3.4.1 Processing Time–Add, Modify, Delete = 3 seconds for 95%

3.4.1.1 Processing Time–Add, Modify, and Delete is applicable to the SRS as accessed through the XRP protocol defined in Appendix C of the Registry Agreement. It measures the processing time for add, modify, and delete transactions associated with domain names, nameserver, contacts, and registrar profile information.

3.4.1.2 The Performance Specification is 3 seconds for 95% of the transactions processed. That is, 95% of the transactions will take 3 seconds or less from the time the Registry Operator receives the request to the time it provides a response.

3.4.2 Processing Time–Query Domain = 1.5 seconds for 95%

3.4.2.1 Processing Time–Query Domain is applicable to the SRS as accessed through the XRP protocol defined in Appendix C of the Registry Agreement. It measures the processing time for an availability query of a specific domain name.

3.4.2.2 The performance specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Registry Operator receives the query to the time it provides a response as to the domain name's availability.

3.4.3 Processing Time–Whois Query = 1.5 seconds for 95%

3.4.3.1 Processing Time–Whois Query is only applicable to the Whois. It measures the processing time for a Whois Query.

3.4.3.2 The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time the Whois receives a query to the time it responds.

3.4.4 Processing Time–Nameserver Resolution = 1.5 seconds for 95%

3.4.4.1 Processing Time–Nameserver Resolution is only applicable to the Nameserver. It measures the processing time for a DNS query.

3.4.4.2 The Performance Specification is 1.5 seconds for 95% of the transactions. That is, 95% of the transactions will take 1.5 seconds or less from the time Nameserver receives the DNS query to the time it provides a response.

3.5 Update Frequency. There are two important elements of the Registry that are updated frequently and are used by the general public; Nameserver and Whois. Registrars generate these updates through the SRS. The SRS then updates the Nameserver and the Whois. These will be done on a batch basis. Update Frequency Performance Specifications are a C3 priority level.

The committed Performance Specification with regard to Update Frequency for both the Nameserver and the Whois is 15 minutes for 95% of the transactions. That is, 95% of the updates to the Nameserver and Whois will be effectuated within 15 minutes. This is measured from the time that the registry confirms the update to the registrar to the time the update appears in the Nameserver and Whois. Update Frequency Performance Specifications have a monthly Service Level Measurement Period and will be reported on a monthly basis.

3.5.1 Update Frequency–Nameserver = 15 minutes for 95%.

3.5.2 Update Frequency–Whois = 15 minutes for 95%.

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

2. Credits. If Registry Operator fails to meet the Performance Specifications defined in Exhibit G ("Service Level Exception" or "SLE"), Registry Operator shall pay in the aggregate to the Registrar Community a credit according to the tables provided below ("Applicable Credit"). Each Registrar shall only be entitled to a fraction of the Applicable Credit. Such fractions of the credit specified in the tables to be paid to any individual Registrar will be calculated based upon the number of domain names that such Registrar added to the Registry during the Service Level Measurement Period compared to the total number of domain names added to the Registry by all Registrars during the Service Level Measurement Period in which the SLE occurred. The credit due to Registrar may be paid as an offset to registrations and other fees owed to Registry Operator by Registrar. All credits shall be paid in U.S. Dollars. The following Credit Lookup Matrix indicates the corresponding credit table for which the credits defined in this Appendix will be levied.

	Performance Specification Description	SRS	Nameserver	Whois
1	Service Availability	Table C1a	Table C1b	Table C1a
2	Processing Time - Add, Modify, Delete	Table C2	NA	NA
3	Processing Time - Query Domain	Table C2	NA	NA
4	Processing Time - Whois	NA	NA	Table C2
5	Processing Time - Nameserver Resolution	NA	Table C2	NA
6	Update Frequency	NA	Table C3	Table C3
7	Planned Outage - Duration	Table C4b	NA	Table C4b
8	Planned Outage - Timeframe	Table C4a	NA	Table C4a
9	Planned Outage - Notification	Table C4a	NA	Table C4a
10	Extended Planned Outage - Duration	Table C4b	NA	Table C4b
11	Extended Planned Outage - Timeframe	Table C4a	NA	Table C4a
12	Extended Planned Outage - Notification	Table C4a	NA	Table C4a

If one or more SLEs occurs as the direct result of a failure to meet a Performance Specification in a single credit class, Registry Operator shall be responsible only for the credit assessed for the credit class which is the proximate cause for all directly related failures.

The following tables identify total Registrar Community credits due for SLEs in the four credit classes C1 - C4. Notwithstanding the credit levels contained in these tables, the total credits owed by Registry Operator under this Agreement shall not exceed $ 30,000 USD monthly and $ 360,000 USD annually. The credits contained in Tables C1a-C4 represent the total credits that may be assessed in a given SLR category in one Service Level Measurement Period.

2.1 C1 Credit Class–If availability of C1 Credit Class components or systems does not meet C1 Performance Specifications in any given Service Level Measurement Period described in the Performance Specification Matrix in Exhibit G, Registry Operator will credit the Registrar Community according to the tables (which amount will be credited to the Registrar on a proportional basis as set forth above).

C1a Availability Example: In a given measurement period, the SRS Availability is 99.87%, which equates to 52 minutes of unplanned downtime. The Registry Operator's Performance Specification for SRS Availability is 99.9%, or 43 minutes of downtime. The Service Level Exception, therefore, is 9 minutes (52-43 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1a. In Table C1a, the time interval (2-10 minutes) has a corresponding credit of $3,750 USD to be paid to the Registrar Community.

C1b Availability Example: In a given Service Level Measurement Period, the measured Nameserver Availability is 99.990% over a twelve (12) month period, which equates to 52 minutes of downtime. The Registry Operator's Performance Specification for Nameserver Availability is 99.999%, or 5minutes of downtime per calendar year. The Service Level Exception, therefore, is 47 minutes (52-5 minutes), the difference between the Performance Specification and the actual measured performance. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C1b. In Table C1b, the time interval (30-60 minutes) has a corresponding credit of $25,000 USD to be paid to the Registrar Community.

2.2 C2 Credit Class–If processing time for C2 Credit Class services does not meet C2 Service Levels in any given Service Level Measurement Period, Registry Operator will credit the Registrar Community according to the following table (which amount will be credited to the Registrars on a proportional basis as set forth above).

C2 Processing Example: The Performance Specification for Processing Time for Add, Modify, and Delete is 3 seconds or less for 95% of the transactions. In a given Service Level Measurement Period 7% of the transactions are greater than 3 seconds. The 5% of those transactions with the longest processing times are not subject to the SLE calculation (3 seconds for 95%). The SLE is calculated using the average processing time for the 2% of the transactions that are subject to the SLE. If there were 1,000 transactions and they took a total of 4,000 seconds the average is 4 seconds. That generates an SLE of 1 second (4 seconds - 3 seconds). From the Credit Lookup Matrix, we see the relevant SLA is found in Table C2. In Table C2, the SLE time interval (< 2 seconds) has a corresponding credit $375 USD to be paid to the Registrar Community.

2.3 C3 Credit Class–If update frequency measurements of C3 Credit Class components or systems do not meet C3 Service Levels in any given Service Level Measurement Period as described in the Performance Specification Matrix in Exhibit G, Registry Operator will credit the Registrar Community according to the following tables (which amount will be credited to the Registrars on a proportional basis as set forth above).

C3 Update Frequency Example: In a given Service Level Measurement Period, 95% of the updates to the Nameserver take 24 minutes or less to complete. The corresponding Registry Operator's Performance Specification is 15 minutes for 95% of the updates. The SLE, therefore, is 9 minutes. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C3. The SLE time interval (2-10 minutes) has a corresponding credit of $938 USD to be paid to the Registrar Community.

2.4 C4 Credit Class–If Registry Operator fails to comply with C4 Credit Class category Performance Specifications, Registry Operator will credit the Registrar Community according to the following tables (C4a and C4b) (which amount will be credited to the Registrars on a proportional basis as set forth above).

C4a Planned Outage Notification Example: In each instance the Registry Operator fails to meet the Performance Specifications for Notification and Timeframe related to Planned Outages and Extended Planned Outages, the Registry Operator is subject to the credit in Table C4a. For example, the Registry Operator informs the Registrar Community that it will initiate a Planned Outage of the SRS on the next calendar Sunday (five (5) days advance notice). The corresponding Registry Operator's Performance Specification is 28 days notice. From the Credit Lookup Matrix, we see the relevant SLA is found in Table C4a. This results in a credit of $500 USD to be paid to the Registrar Community.

C4b Planned Outage Example: In a given Service Level Measurement Period, the actual duration of a planned outage is 11 hours and 20 minutes for the SRS. The corresponding Registry Operator's Performance Specification is 8 hours per month for the SRS. The SLE, therefore, is 3 hours and 20 minutes. From the Credit Lookup Matrix the relevant SLA is found in Table C4b. The SLE time interval (2-4 hours) has a corresponding credit of $1,200 USD to be paid to the Registrar Community.

3. Receipt of Credits. In order for Registrars to claim credits, the following procedure must be followed:

3.1 Registry Operator shall perform the required measurements in order to obtain the total credits associated with the applicable Service Level Measurement Period. Such measurements and associated documentation shall be delivered by e-mail to each of the Registrars in the Registrar Community. Such notice shall also include the total credit (if any) to be paid to the Registrar Community as a result of any outages.

3.2 Receipt of Credit - When the above steps have been completed, the Registry Operator shall enter in each Registrar's account balance the amount of credit (if applicable) that can be used immediately toward registrations in the Registry.

4. Obligations.

4.1 Except in the case of cross-network nameserver performance (which is not a subject of this Service Level Agreement), Registry Operator will perform monitoring from internally located systems as a means to verify that the conditions of the SLA are being met.

4.2 Upon written request, and at the sole expense of the requesting Registrar(s), Registry Operator will retain an independent third party to be selected by Registry Operator with the consent of the Registrar(s). The Registrar may, under reasonable terms and conditions, audit the reconciliation records for the purposes of verifying measurements of the Performance Specifications. The frequency of these audits will be no more than once yearly during the term of the agreement between Registry Operator and the Registrar.

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

4.4 A Registrar must report each occurrence of alleged occasion of Unavailability of Core Services to the Registry Operator customer service help desk in the manner required by the Registry Operator (i.e., e-mail, fax, telephone) in order for an occurrence to be treated as Unavailable for purposes of the SLE.

4.5 In the event that the Core Services are Unavailable to an individual Registrar, Registry Operator will use commercially reasonable efforts to re-establish the affected Core Services for such Registrar as soon as reasonably practicable. In the event that the Unavailability of Core Services 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.

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

4.7 Beginning no later than 120 days post 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.

4.8 The Registry Operator will use commercial reasonable efforts to restore the critical systems of the Core Services within 24 hours after the termination of a force majeure event and restore full system functionality within 48 hours after the termination of a force majeure event. Outages due to a force majeure will not be considered Service Unavailability.

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

5. Miscellaneous.

5.1 This Service Level Agreement is independent of any rights, obligations or duties set forth in the Registry Agreement. In the event of any conflict between the terms and conditions of this Agreement and the Registry Agreement, the Registry Agreement shall control.