.AERO TLD Sponsorship Registry Agreement

(10 September 2021)

 

This TLD SPONSORSHIP REGISTRY AGREEMENT (this “Agreement”) is entered into and made effective as of 10 September 2021 by and between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation (“ICANN”), and SITA Information Networking Computing USA, Inc., a Delaware corporation.

 

 

ARTICLE I INTRODUCTION

 

Section 1.1 Effective Date. The Effective Date for purposes of this Agreement shall be the date first written above, and shall be concurrent with the termination of the existing TLD Sponsorship Agreement between Sponsor (as defined below) and ICANN for the TLD, which will be superseded and replaced in its entirety by this Agreement as of the date hereof.

 

Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement applies is .aero (“TLD”).

 

Section 1.3 Designation as Sponsor. Upon the Effective Date and throughout the Term (as defined in Section 4.1 hereof), unless earlier terminated pursuant to Article VI hereof, ICANN hereby designates SITA Information Networking Computing USA, Inc. as the sole registry operator and sponsoring organization for the TLD (“Sponsor” or “Registry Operator”). ICANN hereby delegates to Sponsor the authority to develop policies for the TLD consistent with the requirements of Section 3.1(f) of this Agreement and the provisions set forth in Specification 12 of this Agreement.

 

 

ARTICLE II REPRESENTATIONS AND WARRANTIES

 

Section 2.1 Due Organization; Authorization and Execution by Registry Operator. Registry Operator is a corporation, duly organized, validly existing and in good standing under the laws of Delaware, and Registry Operator has all requisite power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by Registry Operator into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by Registry Operator.

 

Section 2.2 Due Organization; Authorization and Execution by ICANN. ICANN is a nonprofit public benefit corporation duly organized, validly existing and in good standing under the laws of California. ICANN has all requisite corporate power and authority to enter into this Agreement. All corporate approvals and actions necessary for the entrance by ICANN into this Agreement have been obtained and this Agreement has been duly and validly executed and delivered by ICANN.

 

 

ARTICLE III COVENANTS

 

Section 3.1 Covenants of Registry Operator. Registry Operator covenants and agrees with ICANN as follows:

 

(a) Compliance with Consensus Policies and Temporary Policies. Registry Operator shall comply with and implement all Consensus Policies and Temporary Policies found at <http://www.icann.org/general/consensus-policies.htm>, as of the Effective Date and as may in the future be developed and adopted in accordance with the ICANN Bylaws, provided such future Consensus Polices and Temporary Policies are adopted in accordance with the procedure and relate to those topics and subject to those limitations set forth in Specification 1 attached hereto (“Specification 1”).

 

(b) Handling of Registry Data.

 

(i) Data Escrow. Registry Operator shall comply with the registry data escrow procedures set forth in Specification 2 attached hereto (“Specification 2”).

 

(ii) Personal Data. Registry Operator shall (i) notify each ICANN-accredited registrar that is party to the Registry-Registrar Agreement for the TLD of the purposes of which data about any identified or identifiable natural person (“Personal Data”) submitted to Registry Operator by such registrar is collected and used under this Agreement or otherwise and the intended recipients (or categories of recipients) of such Personal Data, and (ii) require such registrar to obtain the consent of each registrant in the TLD for such collection and use of Personal Data. Registry Operator shall take reasonable steps to protect Personal Data collected from such registrar 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.

 

(iii) Monthly Reporting. Within twenty (20) calendar days following the end of each calendar month, commencing with the first calendar month in which the TLD is delegated in the root zone, Registry Operator shall deliver to ICANN reports in the format set forth in Specification 3 attached hereto (“Specification 3”).

 

(iv) Publication of Registration Data. Registry Operator shall provide access to registration data in accordance with Specification 4 attached hereto (“Specification 4”).

 

(c) Registry Operator’s Registry Operations.

 

(i) Registration Restrictions.

 

(A) Registry Operator shall establish registration policies with respect to the TLD for (i) naming conventions within the TLD, (ii) requirements for registration by members of the TLD community, and (iii) use of registered domain names in conformity with the stated purpose of the community-based TLD. Registry Operator shall operate the TLD in a manner that allows the TLD community to discuss and participate in the development and modification of policies and practices for the TLD. Registry Operator shall establish procedures for the enforcement of registration policies for the TLD, and resolution of disputes concerning compliance with TLD registration policies, and shall enforce such registration policies. Registry Operator agrees to implement and be bound by the Registry Restrictions Dispute Resolution Procedure as set forth at http://www.icann.org/en/resources/registries/rrdrp, with respect to disputes arising pursuant to this Section 3.1(c)(i)(A). Registry Operator shall implement and comply with the community registration policies and other terms set forth on Specification 12 attached hereto.

 

(B) Registry Operator shall reserve, and not register any TLD strings appearing on the list of reserved TLD strings attached as Specification 5 hereto (“Specification 5”). Except to the extent ICANN otherwise authorizes in writing, Registry Operator shall comply with the requirements of Specification 5. Registry Operator may at any time establish or modify policies concerning Registry Operator’s ability to reserve (i.e., withhold from registration or allocate to Registry Operator, but not register to third parties, delegate, use, activate in the DNS or otherwise make available) or block additional character strings within the TLD at its discretion. Except as specified in Specification 5, if Registry Operator is the registrant for any domain names in the registry TLD, such registrations must be through an ICANN accredited registrar, and will be considered transactions for purposes of calculating the Registry-Level Transaction Fee to be paid to ICANN by Registry Operator pursuant to Section 7.2.

 

(ii) Use of ICANN-Accredited Registrars. Registry Operator shall ensure that all Approved Services are provided through one or more ICANN-Accredited Registrars, except to the extent that (a) Specification 12 – Part II delegates to Registry Operator the authority to provide or to arrange for the provision of ENS Services by means other than ICANN-Accredited Registrars or (b) the Registry Operator provides for a different means of providing Approved Services in accordance with its delegation of authority and with the consent of its community and ICANN, such consent not being unreasonably withheld. Registry Operator shall ensure that Registry-Registrar Agreements are in conformance with Section 7.1 of this Agreement.

 

(iii) Registry Services; Additional Services. Registry Operator shall be entitled to provide the Registry Services described in clauses (a) and (b) of the first paragraph of Section 2.1 in the Specification 6 attached hereto (“Specification 6”) and such other Registry Services set forth on Exhibit A (collectively, the “Approved Services”). If Registry Operator desires to provide any Registry Service that is not an Approved Service or is a material modification to an Approved Service (each, an “Additional Service”), Registry Operator shall submit a request for approval of such Additional Service pursuant to the Registry Services Evaluation Policy at http://www.icann.org/en/registries/rsep/rsep.html, as such policy may be amended from time to time in accordance with the bylaws of ICANN (as amended from time to time, the “ICANN Bylaws”) applicable to Consensus Policies (the “RSEP”). Registry Operator may offer Additional Services only with the written approval of ICANN, and, upon any such approval, such Additional Services shall be deemed Approved Services under this Agreement. In its reasonable discretion, ICANN may require an amendment to this Agreement reflecting the provision of any Additional Service which is approved pursuant to the RSEP, which amendment shall be in a form reasonably acceptable to the parties.

 

(iv) Registry Interoperability and Continuity. Registry Operator shall comply with the Registry Interoperability and Continuity Specifications as set forth in Specification 6.

 

(v) Protection of Legal Rights of Third Parties. Registry Operator must comply with, the processes and procedures for ongoing protections of the legal rights of third parties as set forth Specification 7 attached hereto (“Specification 7”). Registry Operator may, at its election, implement additional protections of the legal rights of third parties. Any changes or modifications to the process and procedures required by Specification 7 following the Effective Date must be approved in advance by ICANN in writing. Registry Operator must comply with all remedies imposed by ICANN pursuant to Section 2 of Specification 7, subject to Registry Operator’s right to challenge such remedies as set forth in the applicable procedure described therein. Registry Operator shall take reasonable steps to investigate and respond to any reports from law enforcement and governmental and quasi-governmental agencies of illegal conduct in connection with the use of the TLD. In responding to such reports, Registry Operator will not be required to take any action in contravention of applicable law.

 

(vi) Code of Conduct. In connection with the operation of the registry for the TLD, Registry Operator shall comply with the Registry Code of Conduct as set forth in Specification 9 attached hereto (“Specification 9”).

 

(vii) Registry Performance Specifications. Registry Performance Specifications for operation of the TLD will be as set forth in Specification 10 attached hereto (“Specification 10”). Registry Operator shall comply with such Performance Specifications and, for a period of at least one (1) year, shall keep technical and operational records sufficient to evidence compliance with such specifications for each calendar year during the Term.

 

(viii) Additional Public Interest Commitments. Registry Operator shall comply with the public interest commitments set forth in Specification 11 attached hereto (“Specification 11”).

 

(ix) Emergency Transition. Registry Operator agrees that, in the event that any of the emergency thresholds for registry functions set forth in Section 6 of Specification 10 is reached, ICANN may designate an emergency interim registry operator of the registry for the TLD (an “Emergency Operator”) in accordance with ICANN’s registry transition process (available at <http://www.icann.org/en/resources/registries/transition-processes>) (as the same may be amended from time to time, the “Registry Transition Process”) until such time as Registry Operator has demonstrated to ICANN’s reasonable satisfaction that it can resume operation of the registry for the TLD without the reoccurrence of such failure. Following such demonstration, Registry Operator may transition back into operation of the registry for the TLD pursuant to the procedures set out in the Registry Transition Process, provided that Registry Operator pays all reasonable costs incurred (i) by ICANN as a result of the designation of the Emergency Operator and (ii) by the Emergency Operator in connection with the operation of the registry for the TLD, which costs shall be documented in reasonable detail in records that shall be made available to Registry Operator. In the event ICANN designates an Emergency Operator pursuant to this Section 3.1(d)(ix) and the Registry Transition Process, Registry Operator shall provide ICANN or any such Emergency Operator with all data (including the data escrowed in accordance with Section 3.1(b)(i)) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such Emergency Operator. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and WHOIS records with respect to the TLD in the event that an Emergency Operator is designated pursuant to this Section 3.1(c)(ix).

 

(d) Fees and Payments. Registry Operator shall pay the Registry-Level Fees to ICANN on an annual basis in accordance with Section 7.2 hereof.

 

(e) Cooperation. Registry Operator shall cooperate with ICANN in efforts to promote and facilitate the Security and Stability of the Internet and maintain a reliable and stable DNS. To this end, Registry Operator shall provide such data and assistance to ICANN as it may reasonably request from time to time.

 

(f) General Obligations of Registry Operator / Sponsor to TLD Community. During the Term of this Agreement, Registry Operator / Sponsor shall, in developing or enforcing standards, policies, procedures, or practices within the scope of its delegated authority with respect to the TLD:

 

(i) publish such standards, policies, procedures, and practices so they are available to members of the TLD community;

 

(ii) conduct its policy-development activities in a manner that reasonably provides opportunities for members of the TLD community to discuss and participate in the development of such standards, policies, procedures, or practices;

 

(iii) maintain the representativeness of its policy-development and implementation process by establishing procedures that facilitate participation by a broad cross-section of the TLD community; and

 

(iv) ensure, through published procedures, adequate opportunities for members of the TLD community to submit their views on and objections to the establishment or revision of standards, policies, procedures, and practices or the manner in which standards, policies, procedures, and practices are enforced.

 

Section 3.2 Covenants of ICANN. ICANN covenants and agrees with Registry Operator as follows:

 

(a) Open and Transparent. Consistent with ICANN’s expressed mission and core values, ICANN shall operate in an open and transparent manner.

 

(b) Equitable Treatment. ICANN shall not apply standards, policies, procedures or practices arbitrarily, unjustifiably, or inequitably and shall not single out Registry Operator for disparate treatment unless justified by substantial and reasonable cause.

 

(c) TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at http:/www.iana.org/domains/root/) will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.

 

(d) Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at http://www.icann/org/domains/root.

 

(e) Authoritative Root Database. To the extent that ICANN is authorized to set policy with regard to an authoritative root server system (the “Authoritative Root Server System”), ICANN shall use commercially reasonable efforts to (i) ensure that the authoritative root will point to the top-level domain nameservers designated by Registry Operator for the TLD, (ii) maintain a stable, secure, and authoritative publicly available database of relevant information about the TLD, in accordance with ICANN publicly available policies and procedures, and (iii) coordinate the Authoritative Root Server System so that it is operated and maintained in a stable and secure manner; provided, that ICANN shall not be in breach of this Agreement and ICANN shall have no liability in the event that any third party (including any governmental entity or internet service provider) blocks or restricts access to the TLD in any jurisdiction.

 

Section 3.3 Contractual and Compliance Audits.

 

(a) ICANN may from time to time (not to exceed twice per calendar year) conduct, or engage a third party to conduct, contractual compliance audits to assess compliance by Registry Operator with its representations and warranties contained in Article II of this Agreement and its covenants contained in Article III and Section 7.1 of this Agreement. Such audits shall be tailored to achieve the purpose of assessing compliance, and ICANN will (i) give reasonable advance notice of any such audit, which notice shall specify in reasonable detail the categories of documents, data and other information requested by ICANN and (ii) use commercially reasonable efforts to conduct such audit in such a manner as to not unreasonably disrupt the operations of Registry Operator. As part of such audit and upon request by ICANN, Registry Operator shall timely provide all responsive documents, data and any other information necessary to demonstrate Registry Operator’s compliance with this Agreement. Upon no less than ten (10) calendar days’ notice (unless otherwise agreed to by Registry Operator), ICANN may, as part of any contractual compliance audit, conduct site visits during regular business hours to assess compliance by Registry Operator with its representations and warranties contained in Article II of this Agreement and its covenants contained in Article III and Section 7.1.

 

(b) Any audit conducted pursuant to Section 3.3(a) will be at ICANN’s expense, unless (i) Registry Operator (A) controls, is controlled by, is under common control or is otherwise Affiliated with, any ICANN accredited registrar or registrar reseller or any of their respective Affiliates, or (B) has subcontracted the provision of Registry Services to an ICANN accredited registrar or registrar reseller or any of their respective Affiliates, and, in either case of (A) or (B) above, the audit relates to Registry Operator’s compliance with Section 3.1(c)(vi), in which case Registry Operator shall reimburse ICANN for all reasonable costs and expenses associated with the portion of the audit related to Registry Operator’s compliance with Section 3.1(c)(vi), or (ii) the audit is related to a discrepancy in the fees paid by Registry Operator hereunder in excess of 5% to ICANN’s detriment, in which case Registry Operator shall reimburse ICANN for all reasonable costs and expenses associated with the entirety of such audit. In either such case of (i) or (ii) above, such reimbursement will be paid together with the next Registry-Level Fee payment due following the date of transmittal of the cost statement for such audit.

 

(c) Notwithstanding Section 3.3(a), if Registry Operator is found not to be in compliance with its representations and warranties contained in Article II of this Agreement or its covenants contained in Article III or Section 7.1 of this Agreement in two consecutive audits conducted pursuant to Section 3.3(a), ICANN may increase the number of such audits to one per calendar quarter.

 

(d) Registry Operator will give ICANN immediate notice of Registry Operator’s knowledge of the commencement of any of the proceedings referenced in Section 6.1(b) or the occurrence of any of the matters specified in Section 6.1(d).

 

 

ARTICLE IV TERM OF AGREEMENT

 

Section 4.1 Term. The initial term of this Agreement shall be ten (10) years from the Effective Date (the “Expiration Date”). Registry Operator agrees that upon the earlier of (i) termination of this Agreement by ICANN in accordance with Article VI below or (ii) the Expiration Date, it will cease to be the registry operator for the TLD, unless, with respect to termination under the foregoing clause (ii), Registry Operator and ICANN agree on terms for renewal of the Agreement as set forth in Section 4.2 below prior to the Expiration Date (together, the initial and any renewal terms shall constitute the “Term.”)

 

Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the initial term set forth in Section 4.1 above, and following any renewal term, unless: (i) an arbitrator or court has determined that Registry Operator has been in fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1; Section 3.3; Section 5.2; Section 7.1; or Section 7.2 despite notice and an opportunity to cure in accordance with Article VI hereof and (ii) following the final decision of such arbitrator or court, Registry Operator has failed to correct the conduct found to constitute such breach; provided, however, that Registry Operator agrees that any renewal of this Agreement is conditioned on its negotiation of renewal terms acceptable to ICANN, including, but not limited to, provisions relating to Registry-Level Fees. The parties agree to initiate negotiations with respect to renewal of this Agreement at least six (6) months prior to the Expiration Date or the expiration of any renewal term thereafter, as applicable, then, unless the parties mutually agree to extend the Term and continue negotiations, the matter shall be determined pursuant to the dispute resolution provisions of Article V hereto.

 

Section 4.3 Changes. While this Agreement is in effect, the parties agree to engage in good faith negotiations at regular intervals (at least once every three calendar years following the Effective Date) regarding possible changes to the terms of the Agreement, including to Section 7.2 regarding fees and payments to ICANN.

 

Section 4.4 Failure to Perform in Good Faith. In the event Registry Operator shall have been repeatedly and willfully in fundamental and material breach of Registry Operator’s obligations set forth in Sections 3.1; Section 3.3; Section 5.2; Section 7.1; or Section 7.2, and arbitrators in accordance with Section 5.1(b) of this Agreement repeatedly have found Registry Operator to have been in fundamental and material breach of this Agreement, including in at least three separate awards, then ICANN may request the arbitrators award such punitive, exemplary or other damages as they may believe appropriate under the circumstances.

 

 

ARTICLE V DISPUTE RESOLUTION

 

Section 5.1 Resolution of Disputes.

 

(a) Mediation. In the event of any dispute arising under or in connection with this Agreement, before either party may initiate arbitration pursuant to Section 5.1(b) below, ICANN and Registry Operator must attempt to resolve the dispute through mediation in accordance with the following terms and conditions:

 

(i) A party shall submit a dispute to mediation by written notice to the other party. The mediation shall be conducted by a single mediator selected by the parties. If the parties cannot agree on a mediator within fifteen (15) calendar days of delivery of written notice pursuant to this Section 5.1(a), the parties will promptly select a mutually acceptable mediation provider entity, which entity shall, as soon as practicable following such entity’s selection, designate a mediator, who is a licensed attorney with general knowledge of contract law, has no ongoing business relationship with either party and, to the extent necessary to mediate the particular dispute, general knowledge of the domain name system. Any mediator must confirm in writing that he or she is not, and will not become during the term of the mediation, an employee, partner, executive officer, director, or security holder of ICANN or Registry Operator. If such confirmation is not provided by the appointed mediator, then a replacement mediator shall be appointed pursuant to this Section 5.1(a)(i).

 

(ii) The mediator shall conduct the mediation in accordance with the rules and procedures that he or she determines following consultation with the parties. The parties shall discuss the dispute in good faith and attempt, with the mediator’s assistance, to reach an amicable resolution of the dispute. The mediation shall be treated as a settlement discussion and shall therefore be confidential and may not be used against either party in any later proceeding relating to the dispute, including any arbitration pursuant to Section 5.1(b). The mediator may not testify for either party in any later proceeding relating to the dispute.

 

(iii) Each party shall bear its own costs in the mediation. The parties shall share equally the fees and expenses of the mediator. Each party shall treat information received from the other party pursuant to the mediation that is appropriately marked as confidential as the confidential information of such other party.

 

(iv) If the parties have engaged in good faith participation in the mediation but have not resolved the dispute for any reason, either party or the mediator may terminate the mediation at any time and the dispute can then proceed to arbitration pursuant to Section 5.1(b) below. If the parties have not resolved the dispute for any reason by the date that is ninety (90) calendar days following the date of the notice delivered pursuant to Section 5.1(a)(i), the mediation shall automatically terminate (unless extended by agreement of the parties) and the dispute can then proceed to arbitration pursuant to Section 5.1(b) below.

 

(b) Arbitration. Disputes arising under or in connection with this Agreement that are not resolved pursuant to Section 5.1(a), including requests for specific performance, will be resolved through binding arbitration conducted pursuant to the rules of the International Court of Arbitration of the International Chamber of Commerce (the “ICC”). The arbitration will be conducted in the English language and will occur in Los Angeles County, California. Any arbitration will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary damages, or operational sanctions or (ii) the parties agree in writing to a greater number of arbitrators. In the case of clauses (i) or (ii) in the preceding sentence, the arbitration will be in front of three arbitrators with each party nominating one arbitrator for confirmation by the ICC and the two selected arbitrators nominating the third arbitrator for confirmation by the ICC. For an arbitration in front of a sole arbitrator, Registry Operator and ICANN may, by mutual agreement, nominate the sole arbitrator for confirmation by the ICC. If the parties fail to nominate a sole arbitrator or, in the case of an arbitration in front of three arbitrators, either party fails to nominate an arbitrator, in each case within thirty (30) calendar days from the date when a party’s request for arbitration has been received by the other party, or within such additional time as may be allowed by the Secretariat of the Court of the ICC, the arbitrator(s) shall be appointed by the ICC. If any nominated arbitrator is not confirmed by the ICC, the party or persons that appointed such arbitrator shall promptly nominate a replacement arbitrator for confirmation by the ICC. In order to expedite the arbitration and limit its cost, the arbitrator(s) shall establish page limits for the parties’ filings in conjunction with the arbitration, and should the arbitrator(s) determine that a hearing is necessary, the hearing shall be limited to one (1) calendar day, provided that in any arbitration in which ICANN is seeking punitive or exemplary damages, or operational sanctions, the hearing may be extended for one (1) additional calendar day if agreed upon by the parties or ordered by the arbitrator(s) based on the arbitrator(s) independent determination or the reasonable request of one of the parties thereto. The prevailing party in the arbitration will have the right to recover its costs and reasonable attorneys’ fees, which the arbitrator(s) shall include in the awards. In the event the arbitrators determine that Registry Operator has been repeatedly and willfully in fundamental and material breach of its obligations set forth in Section 3.1, Section 3.3, Section 5.2, Section 7.1 or Section 7.2 of this Agreement, ICANN may request the arbitrators award punitive or exemplary damages, or operational sanctions (including without limitation an order temporarily restricting Registry Operator’s right to sell new registrations). Each party shall treat information received from the other party pursuant to the arbitration that is appropriately marked as confidential as the confidential information of such other party. In any litigation involving ICANN concerning this Agreement, jurisdiction and exclusive venue for such litigation will be in a court located in Los Angeles County, California; however, the parties will also have the right to enforce a judgment of such a court in any court of competent jurisdiction.

 

Section 5.2 Specific Performance. Registry Operator and ICANN agree that irreparable damage could occur if any of the provisions of this Agreement was not performed in accordance with its specific terms. Accordingly, the parties agree that they each shall be entitled to seek from the arbitrators specific performance of the terms of this Agreement (in addition to any other remedy to which each party is entitled).

 

Section 5.3 Limitation of Liability. ICANN’s aggregate monetary liability for violations of this Agreement shall not exceed an amount equal to the Registry-Level Fees paid by Registry Operator to ICANN within the preceding twelve-month period pursuant to this Agreement. Registry Operator’s aggregate monetary liability to ICANN for violations of this Agreement shall be limited to an amount equal to the fees, and monetary damages under Section 4.4, if any, due and owing to ICANN under this Agreement within the preceding twelve-month period. In no event shall either party be liable for special, indirect, incidental, punitive, exemplary, or consequential damages arising out of or in connection with this Agreement or the performance or nonperformance of obligations undertaken in this Agreement, except as provided pursuant to Section 4.4 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN THIS AGREEMENT, NEITHER PARTY MAKES ANY WARRANTY, EXPRESS OR IMPLIED, WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A PARTICULAR PURPOSE.

 

 

ARTICLE VI TERMINATION PROVISIONS

 

Section 6.1 Termination by ICANN.

 

(a) ICANN may terminate this Agreement if Registry Operator fails to cure (i) any fundamental and material breach of Registry Operator’s representations and warranties or obligations set forth in Section 2.1; Section 3.1; Section 3.3; Section 5.2 or Section 7.1 or (ii) any breach of Section 7.2, in each case, despite notice and an opportunity to cure in accordance with Section 6.3 after ICANN delivers to Registry Operator written notice of the breach, which notice shall include with specificity the details of the alleged breach.

 

(b) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i) Registry Operator makes an assignment for the benefit of creditors or similar act, (ii) attachment, garnishment or similar proceedings are commenced against Registry Operator, which proceedings are a material threat to Registry Operator’s ability to operate the registry for the TLD, and are not dismissed within sixty (60) calendar days of their commencement, (iii) a trustee, receiver, liquidator or equivalent is appointed in place of Registry Operator or maintains control over any of Registry Operator’s property, (iv) execution is levied upon any material property of Registry Operator that, if levied, would reasonably be expected to materially and adversely affect Registry Operator’s ability to operate the registry for the TLD, (v) proceedings are instituted by or against Registry Operator under any bankruptcy, insolvency, reorganization or other laws relating to the relief of debtors and such proceedings are not dismissed within sixty (60) calendar days of their commencement (if such proceedings are instituted by Registry Operator or its Affiliates) or one hundred and eighty (180) calendar days of their commencement (if such proceedings are instituted by a third party against Registry Operator), or (vi) Registry Operator files for protection under the United States Bankruptcy Code, 11 U.S.C. Section 101, et seq., or a foreign equivalent or liquidates, dissolves or otherwise discontinues its operations or the operation of the TLD.

 

(c) ICANN may, upon thirty (30) calendar days’ notice to Registry Operator, terminate this Agreement pursuant to a determination by any PDDRP panel or RRDRP panel under Section 2 of Specification 7 or a determination by any PICDRP panel under Section 3, or any other applicable Section, of Specification 11, subject to Registry Operator’s right to challenge such termination as set forth in the applicable procedure described therein.

 

(d) ICANN may, upon notice to Registry Operator, terminate this Agreement if (i) Registry Operator knowingly employs any officer who is convicted of a misdemeanor related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing and such officer is not terminated within thirty (30) calendar days of Registry Operator’s knowledge of the foregoing, or (ii) any member of Registry Operator’s board of directors or similar governing body is convicted of a misdemeanor related to financial activities or of any felony, or is judged by a court of competent jurisdiction to have committed fraud or breach of fiduciary duty, or is the subject of a judicial determination that ICANN reasonably deems as the substantive equivalent of any of the foregoing and such member is not removed from Registry Operator’s board of directors or similar governing body within thirty (30) calendar days of Registry Operator’s knowledge of the foregoing.

 

(e) ICANN may, upon thirty (30) calendar days’ notice to Registry Operator, terminate this Agreement as specified in Section 8.5.

 

Section 6.2 Termination by Registry Operator. Registry Operator may terminate this agreement and its designation as Registry Operator for the TLD pursuant to 120 days prior notice in writing to ICANN, and subject to compliance with Section 6.4 hereof.

 

Section 6.3 Notice; Opportunity to Cure. This Agreement may be terminated in the circumstances described in Section 6.1(a) above only following written notice to Registry Operator and Registry Operator’s failure to cure within thirty (30) days after the date ICANN gives such notice of such breach, with Registry Operator being given a reasonable opportunity during that time to initiate arbitration under Section 5.1(b) to determine the appropriateness of such termination under this Agreement. In the event Registry Operator initiates arbitration concerning the appropriateness of such termination by ICANN, Registry Operator may at the same time request that the arbitration panel stay such termination until the arbitration decision is rendered, and that request shall have the effect of staying such termination until the decision or until the arbitration panel has granted an ICANN request for lifting of the stay.

 

Section 6.4 Transition of Registry Operator upon Termination of Agreement. Upon expiration of the Term pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement pursuant to Sections 6.1 or 6.2, the parties agree to work cooperatively to facilitate and implement the transition of the registry for the TLD in accordance with this Section 6.4. Registry Operator shall provide ICANN or any successor registry operator that may be designated by ICANN for the TLD in accordance with this Section 6.4 with all data (including the data escrowed in accordance with Section 3.1(b)(i) hereof) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such successor registry operator. After consultation with Registry Operator, ICANN shall determine whether or not to transition operation of the TLD to a successor registry operator in its sole discretion and in conformance with the Registry Transition Process; provided, however, that (i) ICANN will take into consideration any intellectual property rights of Registry Operator (as communicated to ICANN by Registry Operator) in determining whether to transition operation of the TLD to a successor registry operator and (ii) if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (A) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator or its Affiliates for their exclusive use, (B) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (C) transitioning operation of the TLD is not necessary to protect the public interest, then ICANN may not transition operation of the TLD to a successor registry operator upon the expiration or termination of this Agreement without the consent of Registry Operator (which shall not be unreasonably withheld, conditioned or delayed). For the avoidance of doubt, the foregoing sentence shall not prohibit ICANN from delegating the TLD pursuant to a future application process for the delegation of top-level domains, subject to any processes and objection procedures instituted by ICANN in connection with such application process intended to protect the rights of third parties. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database for DNS and WHOIS records with respect to the TLD in the event of a transition of the TLD pursuant to this Section 6.4.

 

Section 6.5 Ownership Rights. Nothing contained in this Agreement shall be construed as (a) establishing or granting to Registry Operator any property ownership rights or interests of Registry Operator in the TLD or the letters, words, symbols or other characters making up the TLD string or any Registry Data, or (b) affecting any existing intellectual property or ownership rights of Registry Operator.

 

Section 6.6 No Reimbursement. Any and all expenditures, capital investments or other investments made by Registry Operator in connection with this Agreement shall be at Registry Operator’s own risk and ICANN shall have no obligation to reimburse Registry Operator for any such expense, capital expenditure or investment. Registry Operator shall not be required to make any payments to a successor registry operator by reason of registry fees paid to Registry Operator prior to the effective date of (i) any termination or expiration of this Agreement or (ii) transition of the registry, unless any delay in transition of the Registry Operator to a successor operator shall be due to the actions of Registry Operator. Resolution of any dispute concerning such delays will be governed by the Rules of Dispute as described in Section 5.1.

 

Section 6.7      Effect of Termination. Upon any expiration of the Term or termination of this Agreement, the obligations and rights of the parties hereto shall cease, provided that such expiration or termination of this Agreement shall not relieve the parties of any obligation or breach of this Agreement accruing prior to such expiration or termination, including, without limitation, all accrued payment obligations arising under Section 7.2. In addition, Article V, Article VIII, Section 6.4, Section 6.5, Section 6.6, and this Section 6.7 shall survive the expiration or termination of this Agreement. For the avoidance of doubt, the rights of Registry Operator to operate the registry for the TLD shall immediately cease upon any expiration of the Term or termination of this Agreement.

 

 

ARTICLE VII SPECIAL PROVISIONS

 

Section 7.1 Registry-Registrar Agreement.

 

(a) Access to Registry Services. Registry Operator shall make access to Approved Services, including the shared registration system, available to ICANN-accredited registrars. The criteria for the selection of Registrars shall be set forth in Specification 12, Part IV. Following execution of the Registry-Registrar Agreement, provided registrars are in compliance with such agreement, Registry Operator shall provide nondiscriminatory access to Approved Services, including the shared registration system for the TLD. Such nondiscriminatory access shall include without limitation the following:

 

(i) All registrars (including any registrar affiliated with Registry Operator) can connect to the shared registration system gateway for the TLD via the Internet by utilizing the same maximum number of IP addresses and SSL certificate authentication;

 

(ii) Registry Operator has made the current version of the registrar toolkit software accessible to all registrars and has made any updates available to all registrars on the same schedule;

 

(iii) All registrars have the same level of access to customer support personnel via telephone, e-mail and Registry Operator’s website;

 

(iv) All registrars have the same level of access to registry resources to resolve registry/registrar or registrar/registrar disputes and technical and/or administrative customer service issues;

 

(v) All registrars have the same level of access to data generated by Registry Operator to reconcile their registration activities from Registry Operator’s Web and ftp servers;

 

(vi) All registrars may perform basic automated registrar account management functions using the same registrar tool made available to all registrars by Registry Operator; and

 

(vii) The shared registration system does not include, for purposes of providing discriminatory access, any algorithms or protocols that differentiate among registrars with respect to functionality, including database access, system priorities and overall performance.

 

Such Registry-Registrar Agreement may be revised by Registry Operator from time to time, provided however, that any such revisions must be approved in advance by ICANN.

 

(b) Registry Operator Shall Not Act as Own Registrar. Registry Operator shall not act as a registrar with respect to the TLD. This shall not preclude Registry Operator from registering names within the TLD to itself through a request made to an ICANN-accredited registrar.

 

(c) Restrictions on Acquisition of Ownership or Controlling Interest in Registrar. Registry Operator shall not acquire, directly or indirectly, control of, or a greater than fifteen percent ownership interest in, any ICANN-accredited registrar, without ICANN’s prior approval in writing, which approval shall not be unreasonably withheld. If Registry Operator (i) becomes an Affiliate or reseller of an ICANN accredited registrar, or (ii) subcontracts the provision of any Approved Services to an ICANN accredited registrar, registrar reseller or any of their respective Affiliates, then, in either such case of (i) or (ii) above, Registry Operator will give ICANN prompt notice of the contract, transaction or other arrangement that resulted in such affiliation, reseller relationship or subcontract, as applicable, including, if requested by ICANN, copies of any contract relating thereto; provided, that ICANN will not disclose such contracts to any third party other than relevant competition authorities. ICANN reserves the right, but not the obligation, to refer any such contract, transaction or other arrangement to relevant competition authorities in the event that ICANN determines that such contract, transaction or other arrangement might raise competition issues. For the purposes of this Agreement: (i) “Affiliate” means a person or entity that, directly or indirectly, through one or more intermediaries, controls, is controlled by, or is under common control with, the person or entity specified, and (ii) “control” (including the terms “controlled by” and “under common control with”) means the possession, directly or indirectly, of the power to direct or cause the direction of the management or policies of a person or entity, whether through the ownership of securities, as trustee or executor, by serving as an employee or a member of a board of directors or equivalent governing body, by contract, by credit arrangement or otherwise.

 

(d) Compliance Actions. Registry Operator acknowledges that all ICANN-accredited registrars must enter into a registrar accreditation agreement (“RAA”) with ICANN and ICANN may take certain compliance actions in response to an emergency or in accordance with the terms of the RAA, including suspension or termination of a registrar’s accreditation or suspension of a registrar’s ability to create new registered names or initiate inbound transfers of registered names. ICANN may require Registry Operator to take specific actions consistent with ICANN’s authority under the terms of the RAA to: (i) suspend or terminate a registrar’s ability to create new registered names or (ii) transfer registered names to a registrar designated by ICANN.

 

Section 7.2 Fees to be Paid to ICANN.

 

(a) Payment Schedule. Registry Operator shall pay to ICANN either the annual Fixed Registry-Level Fee specified in Section 7.2(b) or the quarterly Registry-Level Transaction Fees specified in Section 7.2(c) to an account designated by ICANN. If applicable, the Fixed Registry-level Fee shall be paid by the 20th day following the end of the relevant fiscal year. Any Registry-Level Transaction Fees, and payments pursuant to Section 7.2(d), if any, shall be paid by the 20th day following the end of each calendar quarter of such year (i.e., on April 20, July 20, October 20 and January 20 for the calendar quarters ending March 31, June 30, September 30 and December 31) to an account designated by ICANN.

 

(b) Fixed Registry-Level Fee. The fixed annual fee shall be based on the level of registered names within the TLD as of 30 June of each year as follows: if fewer than 5,000 registered names, the annual Registry-Level Fee is $500; if 5,000 or more registered names, but fewer than 50,000, the annual Registry-Level Fee is $5,000. If the registry for the TLD shall have 50,000 or more registered names as of such date, Registry Operator shall be subject to a Registry-Level Transaction Fee for each fiscal quarter as outlined in Section 7.2(c) below. As used in this Section 7.2, “registered names” shall mean each annual increment of an initial or renewal (including renewals associated with transfers from one ICANN-accredited registry to another) domain name registration.

 

(c) Registry-Level Transaction Fee. If Registry Operator has in excess of 50,000 registered names as of 30 June, it will be assessed a transaction fee for each fiscal quarter of the ICANN fiscal year. In such event, Registry Operator shall pay ICANN a Registry-Level transaction fee on the schedule provided in Section 7.2(a) in an amount equal to US$0.25 for each annual increment of an initial or renewal (including renewals associated with transfers from one ICANN-accredited registry to another, each a “Transaction”) domain name registration during the calendar quarter to which the Registry-Level Transaction Fee pertains.

 

(d) Variable Registry-Level Fee. If the ICANN accredited registrars (accounting, in the aggregate, for payment of two-thirds of all registrar-level fees (or such portion of ICANN accredited registrars necessary to approve variable accreditation fees under the then-current registrar accreditation agreement), do not approve, pursuant to the terms of their registrar accreditation agreements with ICANN, the variable accreditation fees established by the ICANN Board of Directors for any ICANN fiscal year, upon delivery of notice from ICANN, Registry Operator shall pay to ICANN a variable registry-level fee, which shall be paid on a fiscal quarter basis, and shall accrue as of the beginning of the first fiscal quarter of such ICANN fiscal year (the “Variable Registry-Level Fee”). The fee will be calculated and invoiced by ICANN on a quarterly basis, and shall be paid by Registry Operator within sixty (60) calendar days with respect to the first quarter of such ICANN fiscal year and within twenty (20) calendar days with respect to each remaining quarter of such ICANN fiscal year, of receipt of the invoiced amount by ICANN. The Registry Operator may invoice and collect the Variable Registry-Level Fees from the registrars that are party to a Registry-Registrar Agreement with Registry Operator (which agreement may specifically provide for the reimbursement of Variable Registry-Level Fees paid by Registry Operator pursuant to this Section 7.2(d)); provided, that the fees shall be invoiced to all ICANN accredited registrars if invoiced to any. The Variable Registry-Level Fee, if collectible by ICANN, shall be an obligation of Registry Operator and shall be due and payable as provided in this Section 7.2(d) irrespective of Registry Operator’s ability to seek and obtain reimbursement of such fee from registrars. In the event ICANN later collects variable accreditation fees for which Registry Operator has paid ICANN a Variable Registry-Level Fee, ICANN shall reimburse the Registry Operator an appropriate amount of the Variable Registry-Level Fee, as reasonably determined by ICANN. If the ICANN accredited registrars (as a group) do approve, pursuant to the terms of their registrar accreditation agreements with ICANN, the variable accreditation fees established by the ICANN Board of Directors for a fiscal year, ICANN shall not be entitled to a Variable-Level Fee hereunder for such fiscal year, irrespective of whether the ICANN accredited registrars comply with their payment obligations to ICANN during such fiscal year. The amount of the Variable Registry-Level Fee will be specified for each registrar, and may include both a per-registrar component and a transactional component.

 

(i) The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each ICANN fiscal year but shall not exceed US$0.25 per domain name registration (including renewals associated with transfers from one ICANN accredited registrar to another) per year.

 

(ii) The per-registrar component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each ICANN fiscal year.

 

(e) Cost Recovery for RSTEP. Requests by Registry Operator for the approval of Additional Services pursuant to Section 3.1(c)(iii) may be referred by ICANN to the Registry Services Technical Evaluation Panel (“RSTEP”) pursuant to that process at http://www.icann.org/en/registries/rsep/. In the event that such requests are referred to RSTEP, Registry Operator shall remit to ICANN the invoiced cost of the RSTEP review within fourteen (14) calendar days of receipt of a copy of the RSTEP invoice from ICANN, unless ICANN determines, in its sole and absolute discretion, to pay all or any portion of the invoiced cost of such RSTEP review.

 

(f) Interest on Late Payments. For any payments ten days or more overdue, Registry Operator shall pay interest on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted by applicable law.

 

 

ARTICLE VIII MISCELLANEOUS

 

Section 8.1 Indemnification of ICANN.

 

(a) Registry Operator shall indemnify and defend ICANN and its directors, officers, employees, and agents (collectively, “Indemnitees”) from and against any and all third-party claims, damages, liabilities, costs, and expenses, including reasonable legal fees and expenses, arising out of or relating to intellectual property ownership rights with respect to the TLD, the delegation of the TLD to Registry Operator, Registry Operator’s operation of the registry for the TLD or Registry Operator’s provision of Approved Services, provided that Registry Operator shall not be obligated to indemnify or defend any Indemnitee to the extent the claim, damage, liability, cost or expense arose: (i) due to the actions or omissions of ICANN, its subcontractors, panelists or evaluators specifically related to and occurring during the registry TLD application process (other than actions or omissions requested by or for the benefit of Registry Operator), or (ii) due to a breach by ICANN of any obligation contained in this Agreement or any willful misconduct by ICANN. This Section shall not be deemed to require Registry Operator to reimburse or otherwise indemnify ICANN for costs associated with the negotiation or execution of this Agreement, or with monitoring or management of the parties’ respective obligations hereunder. Further, this Section shall not apply to any request for attorney’s fees in connection with any litigation or arbitration between or among the parties, which shall be governed by Article V or otherwise awarded by a court of competent jurisdiction or arbitrator.

 

(b) For any claims by ICANN for indemnification whereby multiple registry operators (including Registry Operator) have engaged in the same actions or omissions that gave rise to the claim, Registry Operator’s aggregate liability to indemnify ICANN with respect to such claim shall be limited to a percentage of ICANN’s total claim, calculated by dividing the number of total domain names under registration with Registry Operator within the TLD (which names under registration shall be calculated consistently with Article VI hereof for any applicable quarter) by the total number of domain names under registration within all top level domains for which the registry operators thereof are engaging in the same acts or omissions giving rise to such claim. For the purposes of reducing Registry Operator’s liability under Section 8.1(a) pursuant to this Section 8.1(b), Registry Operator shall have the burden of identifying the other registry operators that are engaged in the same actions or omissions that gave rise to the claim, and demonstrating, to ICANN’s reasonable satisfaction, such other registry operators’ culpability for such actions or omissions. For the avoidance of doubt, in the event that a registry operator is engaged in the same acts or omissions giving rise to the claims, but such registry operator(s) do not have the same or similar indemnification obligations to ICANN as set forth in Section 8.1(a) above, the number of domains under management by such registry operator(s) shall nonetheless be included in the calculation in the preceding sentence.

 

Section 8.2 Indemnification Procedures. If any third-party claim is commenced that is indemnified under Section 8.1 above, notice thereof shall be given to ICANN as promptly as practicable. Registry Operator shall be entitled, if it so elects, in a notice promptly delivered to ICANN, to immediately take control of the defense and investigation of such claim and to employ and engage attorneys reasonably acceptable to the indemnified party to handle and defend the same, at the indemnifying party’s sole cost and expense, provided that in all events ICANN shall be entitled to control at its sole cost and expense the litigation of issues concerning the validity or interpretation of ICANN policies or conduct. ICANN shall cooperate, at its own cost, in all reasonable respects with Registry Operator and its attorneys in the investigation, trial, and defense of such claim and any appeal arising therefrom; provided, however, that the indemnified party may, at its own cost and expense, participate, through its attorneys or otherwise, in such investigation, trial and defense of such claim and any appeal arising therefrom. No settlement of a claim that involves a remedy affecting ICANN other than the payment of money in an amount that is indemnified shall be entered into without the consent of ICANN. If Registry Operator does not assume full control over the defense of a claim subject to such defense in accordance with this Section, Registry Operator may participate in such defense, at its sole cost and expense, and ICANN shall have the right to defend the claim in such manner as it may deem appropriate, at the cost and expense of Registry Operator.

 

Section 8.3 No Offset. All payments due under this Agreement shall be made in a timely manner throughout the term of this Agreement and notwithstanding the pendency of any dispute (monetary or otherwise) between Registry Operator and ICANN.

 

Section 8.4 Use of ICANN Name and Logo. ICANN grants to Registry Operator a non-exclusive royalty-free license to state that it is designated by ICANN as the Registry Operator for the TLD and to use a logo specified by ICANN to signify that Registry Operator is an ICANN-designated registry authority. This license may not be assigned or sublicensed by Registry Operator.

 

Section 8.5 Assignment and Subcontracting. Except as set forth in this Section 8.5, neither party may assign any of its rights and obligations under this Agreement without the prior written approval of the other party, which approval will not be unreasonably withheld. For purposes of this Section 8.5, a direct or indirect change of control of Registry Operator or any subcontracting arrangement that relates to any Critical Function (as identified in Section 6 of Specification 10) for the TLD (a “Material Subcontracting Arrangement”) shall be deemed an assignment.

 

(a) Registry Operator must provide no less than thirty (30) calendar days advance notice to ICANN of any assignment or Material Subcontracting Arrangement, and any agreement to assign or subcontract any portion of the operations of the TLD (whether or not a Material Subcontracting Arrangement) must mandate compliance with all covenants, obligations and agreements by Registry Operator hereunder, and Registry Operator shall continue to be bound by such covenants, obligations and agreements. Registry Operator must also provide no less than thirty (30) calendar days advance notice to ICANN prior to the consummation of any transaction anticipated to result in a direct or indirect change of control of Registry Operator.

 

(b) Within thirty (30) calendar days of either such notification pursuant to Section 8.5(a), ICANN may request additional information from Registry Operator establishing (i) compliance with this Agreement and (ii) that the party acquiring such control or entering into such assignment or Material Subcontracting Arrangement (in any case, the “Contracting Party”) and the ultimate parent entity of the Contracting Party meets the ICANN-adopted specification or policy on registry operator criteria then in effect (including with respect to financial resources and operational and technical capabilities), in which case Registry Operator must supply the requested information within fifteen (15) calendar days.

 

(c) Registry Operator agrees that ICANN’s consent to any assignment, change of control or Material Subcontracting Arrangement will also be subject to background checks on any proposed Contracting Party (and such Contracting Party’s Affiliates).

 

(d) If ICANN fails to expressly provide or withhold its consent to any assignment, direct or indirect change of control of Registry Operator or any Material Subcontracting Arrangement within thirty (30) calendar days of ICANN’s receipt of notice of such transaction (or, if ICANN has requested additional information from Registry Operator as set forth above, thirty (30) calendar days of the receipt of all requested written information regarding such transaction) from Registry Operator, ICANN shall be deemed to have consented to such transaction.

 

(e) In connection with any such assignment, change of control or Material Subcontracting Arrangement, Registry Operator shall comply with the Registry Transition Process.

 

(f) Notwithstanding the foregoing, (i) any consummated change of control shall not be voidable by ICANN; provided, however, that, if ICANN reasonably determines to withhold its consent to such transaction, ICANN may terminate this Agreement pursuant to Section 6.1(e), (ii) ICANN may assign this Agreement without the consent of Registry Operator upon approval of the ICANN Board of Directors in conjunction with a reorganization, reconstitution or re-incorporation of ICANN upon such assignee’s express assumption of the terms and conditions of this Agreement, (iii) Registry Operator may assign this Agreement without the consent of ICANN directly to a wholly-owned subsidiary of Registry Operator, or, if Registry Operator is a wholly-owned subsidiary, to its direct parent or to another wholly-owned subsidiary of its direct parent, upon such subsidiary’s or parent’s, as applicable, express assumption of the terms and conditions of this Agreement, and (iv) ICANN shall be deemed to have consented to any assignment, Material Subcontracting Arrangement or change of control transaction in which the Contracting Party is an existing operator of a generic top-level domain pursuant to a registry agreement between such Contracting Party and ICANN (provided that such Contracting Party is then in compliance with the terms and conditions of such registry agreement in all material respects), unless ICANN provides to Registry Operator a written objection to such transaction within ten (10) calendar days of ICANN’s receipt of notice of such transaction pursuant to this Section 8.5. Notwithstanding Section 8.5(a), in the event an assignment is made pursuant to clauses (ii) or (iii) of this Section 8.5(f), the assigning party will provide the other party with prompt notice following any such assignment.

 

Section 8.6 Amendments and Waivers. No amendment, supplement, or modification of this Agreement or any provision hereof shall be binding unless executed in writing by both parties. No waiver of any provision of this Agreement shall be binding unless evidenced by a writing signed by the party waiving compliance with such provision. No waiver of any of the provisions of this Agreement or failure to enforce any of the provisions hereof shall be deemed or shall constitute a waiver of any other provision hereof, nor shall any such waiver constitute a continuing waiver unless otherwise expressly provided.

 

Section 8.7 No Third-Party Beneficiaries. This Agreement shall not be construed to create any obligation by either ICANN or Registry Operator to any non-party to this Agreement, including any registry operator, registrar or registered name holder.

 

Section 8.8 Notices, Designations, and Specifications. All notices to be given under or in relation to this Agreement shall be given either (i) in writing at the address of the appropriate party as set forth below or (ii) via facsimile or electronic mail as provided below, unless that party has given a notice of change of postal or email address, or facsimile number, as provided in this agreement. Any change in the contact information for notice below shall be given by the party within 30 days of such change. Any notice required by this Agreement shall be deemed to have been properly given (i) if in paper form, when delivered in person or via courier service with confirmation of receipt or (ii) if via facsimile or by electronic mail, upon confirmation of receipt by the recipient’s facsimile machine or email server, provided that such notice via facsimile or electronic mail shall be followed by a copy sent by regular postal mail service within two (2) business days. Whenever this Agreement shall specify a URL address for certain information, Registry Operator shall be deemed to have been given notice of any such information when electronically posted at the designated URL. In the event other means of notice shall become practically achievable, such as notice via a secure website, the parties shall work together to implement such notice means under this Agreement.

 

If to ICANN, addressed to:

 

Internet Corporation for Assigned Names and Numbers

12025 Waterfront Drive

Suite 300

Los Angeles, California 90094

Telephone: 1-310-823-9358

Facsimile: 1-310-823-8649

Attention: President and CEO

With a Required Copy to: General Counsel

Email: as specified from time to time

 

If to Registry Operator, addressed to:

 

SITA INC USA, Inc.

3100 Cumberland Boulevard, Suite 900

Atlanta, Georgia 30339

Telephone: 1-770-850-4548

Mobile: 1-404-889-2356

Facsimile: 1-770-955-3225

Attention: Bryan P. Crowell

Director, Regulatory & Government Affairs

Email: bryan.crowell@sita.aero

 

Section 8.9 Language. Notwithstanding any translated version of this Agreement and/or specifications that may be provided to Registry Operator, the English language version of this Agreement and all referenced specifications are the official versions that bind the parties hereto. In the event of any conflict or discrepancy between any translated version of this Agreement and the English language version, the English language version controls. Notices, designations, determinations, and specifications made under this Agreement shall be in the English language.

 

Section 8.10 Counterparts. This Agreement may be executed in one or more counterparts, each of which shall be deemed an original, but all of which together shall constitute one and the same instrument.

 

Section 8.11 Entire Agreement. This Agreement (including its Appendices, which form a part of it) constitutes the entire agreement of the parties hereto pertaining to the operation of the TLD and supersedes all prior agreements, understandings, negotiations and discussions, whether oral or written, between the parties on that subject. In the event of a conflict between the provisions in the body of this Agreement and any provision in its Appendices, the provisions in the body of the Agreement shall control.

 

Section 8.12 Severability. This Agreement shall be deemed severable; the invalidity or unenforceability of any term or provision of this Agreement shall not affect the validity or enforceability of the balance of this Agreement or any other term hereof, which shall remain in full force and effect. If any of the provisions hereof are determined to be invalid or unenforceable, the parties shall negotiate in good faith to modify this Agreement so as to effect the original intent of the parties as closely as possible.

 

Section 8.13 Defined Terms. For purposes of this Agreement, unless such definitions are amended pursuant to a Consensus Policy at a future date, in which case the following definitions shall be deemed amended and restated in their entirety as set forth in such Consensus Policy, Security and Stability shall be defined as follows:

(a) For purposes of this Agreement, an effect on “Security” shall mean (1) the unauthorized disclosure, alteration, insertion or destruction of registry data, or (2) the unauthorized access to or disclosure of information or resources on the Internet by systems operating in accordance with all applicable standards.

 

(b) For purposes of this Agreement, an effect on “Stability” shall refer to (1) lack of compliance with applicable relevant standards that are authoritative and published by a well-established and recognized Internet standards body, such as the relevant Standards-Track or Best Current Practice Requests for Comments (“RFCs”) sponsored by the Internet Engineering Task Force; or (2) the creation of a condition that adversely affects the throughput, response time, consistency or coherence of responses to Internet servers or end systems operating in accordance with applicable relevant standards that are authoritative and published by well-established and recognized Internet standards body, such as the relevant Standards-Track or Best Current Practices RFCs, and relying on Registry Operator’s delegated information or provisioning of services.

 

Section 8.14 Court Orders. ICANN will respect any order from a court of competent jurisdiction, including any orders from any jurisdiction where the consent or non-objection of the government was a requirement for the delegation of the TLD. Notwithstanding any other provision of this Agreement, ICANN’s implementation of any such order will not be a breach of this Agreement


IN WITNESS WHEREOF, the parties hereto have caused this Agreement to be executed by their duly authorized representatives.

 

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

 

 

By: _____________________________

Xavier Calvez

Chief Financial Officer

 

 

SITA INFORMATION NETWORKING COMPUTING USA, INC.

 

 

By: _____________________________

 Harihar Subramanian

 Director Business Finance – Americas

 

 

 

 


EXHIBIT A

Approved Services

The ICANN gTLD Applicant Guidebook (located at http://newgtlds.icann.org/en/applicants/agb) and the RSEP specify processes for consideration of proposed registry services. Registry Operator may provide any service that is required by the terms of this Agreement. In addition, the following services (if any) are specifically identified as having been approved by ICANN prior to the effective date of the Agreement, and Registry Operator may provide such services:

1.     DNS Service – TLD Zone Contents

Notwithstanding anything else in this Agreement, as indicated in section 2.2.3.3 of the gTLD Applicant Guidebook, permissible contents for the TLD’s DNS service are:

1.1.   For the “Internet” (IN) Class:

1.1.1.   Apex SOA record

1.1.2.   Apex NS records and in-bailiwick glue for the TLD’s DNS servers

1.1.3.   NS records and in-bailiwick glue for DNS servers of registered names in the TLD

1.1.4.   DS records for registered names in the TLD

1.1.5.   Records associated with signing the TLD zone (e.g., RRSIG, DNSKEY, NSEC, NSEC3PARAM and NSEC3)

1.1.6.   Apex TXT record for zone versioning purposes

1.1.7.   Apex TYPE65534 record for automatic dnssec signing signaling

1.2.   For the “Chaos” (CH) Class:

1.2.1.   TXT records for server version/identification (e.g., TXT records for “version.bind.”, “id.server.”, “authors.bind” and/or “hostname.bind.”)

(Note: The above language effectively does not allow, among other things, the inclusion of DNS resource records that would enable a dotless domain name (e.g., apex A, AAAA, MX records) in the TLD zone.)

If Registry Operator wishes to place any DNS resource record type or class into its TLD DNS service (other than those listed in Sections 1.1 or 1.2 above), it must describe in detail its proposal and submit a Registry Services Evaluation Process (RSEP) request. This will be evaluated per RSEP to determine whether the service would create a risk of a meaningful adverse impact on security or stability of the DNS. Registry Operator recognizes and acknowledges that a service based on the use of less-common DNS resource records and/or classes in the TLD zone, even if approved, might not work as intended for all users due to lack of software support.

2.     Whois Contact Lookup

Registry Operator may offer the Whois contact lookup service, which is a service that extends the functionality specified in Specification 4 by allowing the end-user to look up for Contact data using the contact ROID as the lookup key:

Query format: whois "contact 5372809-ERL"

Response format:

Contact ID: 5372808-ERL 
Name: EXAMPLE REGISTRANT 
Organization: EXAMPLE ORGANIZATION 
Street: 123 EXAMPLE STREET 
City: ANYTOWN 
State/Province: AP 
Postal Code: A1A1A1 
Country: EX
Phone: +1.5555551212 
Phone Ext: 1234 
Fax: +1.5555551213 
Fax Ext: 4321 
Email: EMAIL@EXAMPLE.TLD 
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

 3.      Implementation Period 

Registry Operator will have a 270 calendar days grace period, beginning on the Effective Date, to work with ICANN and backend providers to ensure that all technical operations and obligations have transitioned from the previous registry agreement for the TLD to this Registry Agreement.

 

 

SPECIFICATION 1

CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION

1.              Consensus Policies.

1.1.         Consensus Policies” are those policies established (1) pursuant to the procedure set forth in ICANN’s Bylaws and due process, and (2) covering those topics listed in Section 1.2 of this Specification. The Consensus Policy development process and procedure set forth in ICANN’s Bylaws may be revised from time to time in accordance with the process set forth therein.

1.2.         Consensus Policies and the procedures by which they are developed shall be designed to produce, to the extent possible, a consensus of Internet stakeholders, including the operators of gTLDs. Consensus Policies shall relate to one or more of the following:

1.2.1      issues for which uniform or coordinated resolution is reasonably necessary to facilitate interoperability, security and/or stability of the Internet or Domain Name System (“DNS”);

1.2.2      functional and performance specifications for the provision of Registry Services;

1.2.3      Security and Stability of the registry database for the TLD;

1.2.4      registry policies reasonably necessary to implement Consensus Policies relating to registry operations or registrars;

1.2.5      resolution of disputes regarding the registration of domain names (as opposed to the use of such domain names); or

1.2.6      restrictions on cross-ownership of registry operators and registrars or registrar resellers and regulations and restrictions with respect to registry operations and the use of registry and registrar data in the event that a registry operator and a registrar or registrar reseller are affiliated.

1.3.         Such categories of issues referred to in Section 1.2 of this Specification shall include, without limitation:

1.3.1      principles for allocation of registered names in the TLD (e.g., first-come/first-served, timely renewal, holding period after expiration);

1.3.2      prohibitions on warehousing of or speculation in domain names by registries or registrars;

1.3.3      reservation of registered names in the TLD that may not be registered initially or that may not be renewed due to reasons reasonably related to (i) avoidance of confusion among or misleading of users, (ii) intellectual property, or (iii) the technical management of the DNS or the Internet (e.g., establishment of reservations of names from registration); and

1.3.4      maintenance of and access to accurate and up-to-date information concerning domain name registrations; and procedures to avoid disruptions of domain name registrations due to suspension or termination of operations by a registry operator or a registrar, including procedures for allocation of responsibility for serving registered domain names in a TLD affected by such a suspension or termination.

1.4.         In addition to the other limitations on Consensus Policies, they shall not:

1.4.1      prescribe or limit the price of Registry Services;

1.4.2      modify the terms or conditions for the renewal or termination of the Registry Agreement;

1.4.3      modify the limitations on Temporary Policies (defined below) or Consensus Policies;

1.4.4      modify the provisions in the registry agreement regarding fees paid by Registry Operator to ICANN; or

1.4.5      modify ICANN’s obligations to ensure equitable treatment of registry operators and act in an open and transparent manner.

2.              Temporary Policies. Registry Operator shall comply with and implement all specifications or policies established by the Board on a temporary basis, if adopted by the Board by a vote of at least two-thirds of its members, so long as the Board reasonably determines that such modifications or amendments are justified and that immediate temporary establishment of a specification or policy on the subject is necessary to maintain the Stability or Security of Registry Services or the DNS (“Temporary Policies”).

2.1.         Such proposed specification or policy shall be as narrowly tailored as feasible to achieve those objectives. In establishing any Temporary Policy, the Board shall state the period of time for which the Temporary Policy is adopted and shall immediately implement the Consensus Policy development process set forth in ICANN’s Bylaws.

2.1.1      ICANN shall also issue an advisory statement containing a detailed explanation of its reasons for adopting the Temporary Policy and why the Board believes such Temporary Policy should receive the consensus support of Internet stakeholders.

2.1.2      If the period of time for which the Temporary Policy is adopted exceeds ninety (90) calendar days, the Board shall reaffirm its temporary adoption every ninety (90) calendar days for a total period not to exceed one (1) year, in order to maintain such Temporary Policy in effect until such time as it becomes a Consensus Policy. If the one (1) year period expires or, if during such one (1) year period, the Temporary Policy does not become a Consensus Policy and is not reaffirmed by the Board, Registry Operator shall no longer be required to comply with or implement such Temporary Policy.

3.              Notice and Conflicts. Registry Operator shall be afforded a reasonable period of time following notice of the establishment of a Consensus Policy or Temporary Policy in which to comply with such policy or specification, taking into account any urgency involved. In the event of a conflict between Registry Services and Consensus Policies or any Temporary Policy, the Consensus Polices or Temporary Policy shall control, but only with respect to subject matter in conflict.


SPECIFICATION 2

DATA ESCROW REQUIREMENTS

Registry Operator will engage an independent entity to act as data escrow agent (“Escrow Agent”) for the provision of data escrow services related to the Registry Agreement. The following Technical Specifications set forth in Part A, and Legal Requirements set forth in Part B, will be included in any data escrow agreement between Registry Operator and the Escrow Agent, under which ICANN must be named a third-party beneficiary. In addition to the following requirements, the data escrow agreement may contain other provisions that are not contradictory or intended to subvert the required terms provided below.

PART A – TECHNICAL SPECIFICATIONS

1.              Deposits. There will be two types of Deposits: Full and Differential. For both types, the universe of Registry objects to be considered for data escrow are those objects necessary in order to offer all of the approved Registry Services.

1.1.         Full Deposit” will consist of data that reflects the state of the registry as of 00:00:00 UTC (Coordinated Universal Time) on the day that such Full Deposit is submitted to Escrow Agent.

1.2.         Differential Deposit” means data that reflects all transactions that were not reflected in the last previous Full or Differential Deposit, as the case may be. Each Differential Deposit will contain all database transactions since the previous Deposit was completed as of 00:00:00 UTC of each day, but Sunday. Differential Deposits must include complete Escrow Records as specified below that were not included or changed since the most recent full or Differential Deposit (i.e., all additions, modifications or removals of data).

2.              Schedule for Deposits. Registry Operator will submit a set of escrow files on a daily basis as follows:

2.1.         Each Sunday, a Full Deposit must be submitted to the Escrow Agent by 23:59 UTC.

2.2.         The other six (6) days of the week, a Full Deposit or the corresponding Differential Deposit must be submitted to Escrow Agent by 23:59 UTC.

3.              Escrow Format Specification.

3.1.         Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in draft-arias-noguchi-registry-data-escrow, see Part A, Section 9, reference 1 of this Specification and draft-arias-noguchi-dnrd-objects-mapping, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. If not already an RFC, Registry Operator will use the most recent draft version of the DNDE Specification available at the Effective Date. Registry Operator may at its election use newer versions of the DNDE Specification after the Effective Date. Once the DNDE Specification is published as an RFC, Registry Operator will implement that version of the DNDE Specification, no later than one hundred eighty (180) calendar days after. UTF-8 character encoding will be used.

3.2.         Extensions. If a Registry Operator offers additional Registry Services that require submission of additional data, not included above, additional “extension schemas” shall be defined in a case by case basis to represent that data. These “extension schemas” will be specified as described in Part A, Section 9, reference 2 of this Specification. Data related to the “extensions schemas” will be included in the deposit file described in Part A, Section 3.1 of this Specification. ICANN and the respective Registry Operator shall work together to agree on such new objects’ data escrow specifications.

4.              Processing of Deposit files. The use of compression is recommended in order to reduce electronic data transfer times, and storage capacity requirements. Data encryption will be used to ensure the privacy of registry escrow data. Files processed for compression and encryption will be in the binary OpenPGP format as per OpenPGP Message Format - RFC 4880, see Part A, Section 9, reference 3 of this Specification. Acceptable algorithms for Public-key cryptography, Symmetric-key cryptography, Hash and Compression are those enumerated in RFC 4880, not marked as deprecated in OpenPGP IANA Registry, see Part A, Section 9, reference 4 of this Specification, that are also royalty-free. The process to follow for the data file in original text format is:

(1)           The XML file of the deposit as described in Part A, Section 9, reference 1 of this Specification must be named as the containing file as specified in Section 5 but with the extension xml.

(2)           The data file(s) are aggregated in a tarball file named the same as (1) but with extension tar.

(3)           A compressed and encrypted OpenPGP Message is created using the tarball file as sole input. The suggested algorithm for compression is ZIP as per RFC 4880. The compressed data will be encrypted using the escrow agent’s public key. The suggested algorithms for Public-key encryption are Elgamal and RSA as per RFC 4880. The suggested algorithms for Symmetric-key encryption are TripleDES, AES128 and CAST5 as per RFC 4880.

(4)           The file may be split as necessary if, once compressed and encrypted, it is larger than the file size limit agreed with the escrow agent. Every part of a split file, or the whole file if not split, will be called a processed file in this section.

(5)           A digital signature file will be generated for every processed file using the Registry Operator’s private key. The digital signature file will be in binary OpenPGP format as per RFC 4880 Section 9, reference 3, and will not be compressed or encrypted. The suggested algorithms for Digital signatures are DSA and RSA as per RFC 4880. The suggested algorithm for Hashes in Digital signatures is SHA256.

(6)           The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. as agreed between the Escrow Agent and the Registry Operator. Non-electronic delivery through a physical medium such as CD-ROMs, DVD-ROMs, or USB storage devices may be used if authorized by ICANN.

(7)           The Escrow Agent will then validate every (processed) transferred data file using the procedure described in Part A, Section 8 of this Specification.

5.              File Naming Conventions. Files will be named according to the following convention: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:

5.1.         {gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII-compatible form (A-Label) must be used;

5.2.         {YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the string to be used would be “2009-08-02”;

5.3.         {type} is replaced by:

(1)          “full”, if the data represents a Full Deposit;

(2)          “diff”, if the data represents a Differential Deposit;

(3)          “thin”, if the data represents a Bulk Registration Data Access file, as specified in Section 3 of Specification 4;

(4)          “thick-{gurid}”, if the data represent Thick Registration Data from a specific registrar, as defined in Section 3.2 of Specification 4. The {gurid} element must be replaced with the IANA Registrar ID associated with the data.

5.4.         {#} is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone file, this must be replaced by “1”.

5.5.         {rev} is replaced by the number of revision (or resend) of the file beginning with “0”:

5.6.         {ext} is replaced by “sig” if it is a digital signature file of the quasi-homonymous file. Otherwise it is replaced by “ryde”.

6.              Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party’s public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted via offline methods, like in person meeting, telephone, etc. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Registry Operator and ICANN will exchange public keys by the same procedure.

7.              Notification of Deposits. Along with the delivery of each Deposit, Registry Operator will deliver to Escrow Agent and to ICANN (using the API described in draft-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 of this Specification (the “Interface Specification”)) a written statement from Registry Operator (which may be by authenticated e-mail) that includes a copy of the report generated upon creation of the Deposit and states that the Deposit has been inspected by Registry Operator and is complete and accurate. The preparation and submission of this statement must be performed by the Registry Operator or its designee, provided that such designee may not be the Escrow Agent or any of Escrow Agent’s Affiliates. Registry Operator will include the Deposit’s “id” and “resend” attributes in its statement. The attributes are explained in Part A, Section 9, reference 1 of this Specification.

If not already an RFC, Registry Operator will use the most recent draft version of the Interface Specification at the Effective Date. Registry Operator may at its election use newer versions of the Interface Specification after the Effective Date. Once the Interface Specification is published as an RFC, Registry Operator will implement that version of the Interface Specification, no later than one hundred eighty (180) calendar days after such publishing.

8.              Verification Procedure.

(1)           The signature file of each processed file is validated.

(2)           If processed files are pieces of a bigger file, the latter is put together.

(3)           Each file obtained in the previous step is then decrypted and uncompressed.

(4)           Each data file contained in the previous step is then validated against the format defined in Part A, Section 9, reference 1 of this Specification.

(5)           The data escrow agent extended verification process, as defined below in reference 2 of Part A of this Specification 2, as well as any other data escrow verification process contained in such reference.

If any discrepancy is found in any of the steps, the Deposit will be considered incomplete.

9.              References.

(1)           Domain Name Data Escrow Specification (work in progress), http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow

(2)           Domain Name Registration Data (DNRD) Objects Mapping, http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping

(3)           OpenPGP Message Format, http://www.rfc-editor.org/rfc/rfc4880.txt

(4)           OpenPGP parameters, http://www.iana.org/assignments/pgp‑parameters/pgp‑parameters.xhtml

(5)           ICANN interfaces for registries and data escrow agents, http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces


PART B – LEGAL REQUIREMENTS

1.              Escrow Agent. Prior to entering into an escrow agreement, the Registry Operator must provide notice to ICANN as to the identity of the Escrow Agent, and provide ICANN with contact information and a copy of the relevant escrow agreement, and all amendments thereto. In addition, prior to entering into an escrow agreement, Registry Operator must obtain the consent of ICANN to (a) use the specified Escrow Agent, and (b) enter into the form of escrow agreement provided. ICANN must be expressly designated as a third-party beneficiary of the escrow agreement. ICANN reserves the right to withhold its consent to any Escrow Agent, escrow agreement, or any amendment thereto, all in its sole discretion.

2.              Fees. Registry Operator must pay, or have paid on its behalf, fees to the Escrow Agent directly. If Registry Operator fails to pay any fee by the due date(s), the Escrow Agent will give ICANN written notice of such non-payment and ICANN may pay the past-due fee(s) within fifteen (15) calendar days after receipt of the written notice from Escrow Agent. Upon payment of the past-due fees by ICANN, ICANN shall have a claim for such amount against Registry Operator, which Registry Operator shall be required to submit to ICANN together with the next fee payment due under the Registry Agreement.

3.              Ownership. Ownership of the Deposits during the effective term of the Registry Agreement shall remain with Registry Operator at all times. Thereafter, Registry Operator shall assign any such ownership rights (including intellectual property rights, as the case may be) in such Deposits to ICANN. In the event that during the term of the Registry Agreement any Deposit is released from escrow to ICANN, any intellectual property rights held by Registry Operator in the Deposits will automatically be licensed to ICANN or to a party designated in writing by ICANN on a non-exclusive, perpetual, irrevocable, royalty-free, paid-up basis, for any use related to the operation, maintenance or transition of the TLD.

4.              Integrity and Confidentiality. Escrow Agent will be required to (i) hold and maintain the Deposits in a secure, locked, and environmentally safe facility, which is accessible only to authorized representatives of Escrow Agent, (ii) protect the integrity and confidentiality of the Deposits using commercially reasonable measures and (iii) keep and safeguard each Deposit for one (1) year. ICANN and Registry Operator will be provided the right to inspect Escrow Agent’s applicable records upon reasonable prior notice and during normal business hours. Registry Operator and ICANN will be provided with the right to designate a third-party auditor to audit Escrow Agent’s compliance with the technical specifications and maintenance requirements of this Specification 2 from time to time.

If Escrow Agent receives a subpoena or any other order from a court or other judicial tribunal pertaining to the disclosure or release of the Deposits, Escrow Agent will promptly notify the Registry Operator and ICANN unless prohibited by law. After notifying the Registry Operator and ICANN, Escrow Agent shall allow sufficient time for Registry Operator or ICANN to challenge any such order, which shall be the responsibility of Registry Operator or ICANN; provided, however, that Escrow Agent does not waive its rights to present its position with respect to any such order. Escrow Agent will cooperate with the Registry Operator or ICANN to support efforts to quash or limit any subpoena, at such party’s expense. Any party requesting additional assistance shall pay Escrow Agent’s standard charges or as quoted upon submission of a detailed request.

5.              Copies. Escrow Agent may be permitted to duplicate any Deposit, in order to comply with the terms and provisions of the escrow agreement.

6.              Release of Deposits. Escrow Agent will make available for electronic download (unless otherwise requested) to ICANN or its designee, within twenty-four (24) hours, at the Registry Operator’s expense, all Deposits in Escrow Agent’s possession in the event that the Escrow Agent receives a request from Registry Operator to effect such delivery to ICANN, or receives one of the following written notices by ICANN stating that:

6.1.         the Registry Agreement has expired without renewal, or been terminated; or

6.2.         ICANN has not received a notification as described in Part B, Sections 7.1 and 7.2 of this Specification from Escrow Agent within five (5) calendar days after the Deposit’s scheduled delivery date; (a) ICANN gave notice to Escrow Agent and Registry Operator of that failure; and (b) ICANN has not, within seven (7) calendar days after such notice, received the notification from Escrow Agent; or

6.3.         ICANN has received notification as described in Part B, Sections 7.1 and 7.2 of this Specification from Escrow Agent of failed verification of the latest escrow deposit for a specific date or a notification of a missing deposit, and the notification is for a deposit that should have been made on Sunday (i.e., a Full Deposit); (a) ICANN gave notice to Registry Operator of that receipt; and (b) ICANN has not, within seven (7) calendar days after such notice, received notification as described in Part B, Sections 7.1 and 7.2 of this Specification from Escrow Agent of verification of a remediated version of such Full Deposit; or

6.4.         ICANN has received five notifications from Escrow Agent within the last thirty (30) calendar days notifying ICANN of either missing or failed escrow deposits that should have been made Monday through Saturday (i.e., a Differential Deposit), and (x) ICANN provided notice to Registry Operator of the receipt of such notifications; and (y) ICANN has not, within seven (7) calendar days after delivery of such notice to Registry Operator, received notification from Escrow Agent of verification of a remediated version of such Differential Deposit; or

6.5.         Registry Operator has: (i) ceased to conduct its business in the ordinary course; or (ii) filed for bankruptcy, become insolvent or anything analogous to any of the foregoing under the laws of any jurisdiction anywhere in the world; or

6.6.         Registry Operator has experienced a failure of critical registry functions and ICANN has asserted its rights pursuant to Section 3.1(c)(ix) of the Agreement; or

6.7.         a competent court, arbitral, legislative, or government agency mandates the release of the Deposits to ICANN; or

6.8.         pursuant to Contractual and Operational Compliance Audits as specified under Section 3.3 of the Agreement.

Unless Escrow Agent has previously released the Registry Operator’s Deposits to ICANN or its designee, Escrow Agent will deliver all Deposits to ICANN upon expiration or termination of the Registry Agreement or the Escrow Agreement.

7.              Verification of Deposits.

7.1.         Within twenty-four (24) hours after receiving each Deposit or corrected Deposit, Escrow Agent must verify the format and completeness of each Deposit and deliver to ICANN a notification generated for each Deposit. Reports will be delivered electronically using the API described in draft-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 of this Specification.

7.2.         If Escrow Agent discovers that any Deposit fails the verification procedures or if Escrow Agent does not receive any scheduled Deposit, Escrow Agent must notify Registry Operator either by email, fax or phone and ICANN (using the API described in draft-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 of this Specification) of such nonconformity or non-receipt within twenty-four (24) hours after receiving the non-conformant Deposit or the deadline for such Deposit, as applicable. Upon notification of such verification or delivery failure, Registry Operator must begin developing modifications, updates, corrections, and other fixes of the Deposit necessary for the Deposit to be delivered and pass the verification procedures and deliver such fixes to Escrow Agent as promptly as possible.

8.              Amendments. Escrow Agent and Registry Operator shall amend the terms of the Escrow Agreement to conform to this Specification 2 within ten (10) calendar days of any amendment or modification to this Specification 2. In the event of a conflict between this Specification 2 and the Escrow Agreement, this Specification 2 shall control.

9.              Indemnity. Escrow Agent shall indemnify and hold harmless Registry Operator and ICANN, and each of their respective directors, officers, agents, employees, members, and stockholders (“Indemnitees”) absolutely and forever from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys’ fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence or misconduct of Escrow Agent, its directors, officers, agents, employees and contractors.


SPECIFICATION 3

FORMAT AND CONTENT FOR REGISTRY OPERATOR MONTHLY REPORTING

Registry Operator shall provide one set of monthly reports per gTLD, using the API described in draft-lozano-icann-registry-interfaces, see Specification 2, Part A, Section 9, reference 5, with the following content.

ICANN may request in the future that the reports be delivered by other means and using other formats. ICANN will use reasonable commercial efforts to preserve the confidentiality of the information reported until three (3) months after the end of the month to which the reports relate. Unless set forth in this Specification 3, any reference to a specific time refers to Coordinated Universal Time (UTC). Monthly reports shall consist of data that reflects the state of the registry at the end of the month (UTC).

1.              Per-Registrar Transactions Report. This report shall be compiled in a comma separated-value formatted file as specified in RFC 4180. The file shall be named “gTLD-transactions-yyyymm.csv”, where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and month being reported. The file shall contain the following fields per registrar:

Field #

Field name

Description

01

registrar-name

Registrar’s full corporate name as registered with IANA

02

iana-id

For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) either 9998 or 9999 should be used depending on registration type (as described in Specification 5), otherwise the sponsoring Registrar IANA id should be used as specified in http://www.iana.org/assignments/registrar-ids

03

total-domains

total domain names under sponsorship in any EPP status but pendingCreate that have not been purged

04

total-nameservers

total name servers (either host objects or name server hosts as domain name attributes) associated with domain names registered for the TLD in any EPP status but pendingCreate that have not been purged

05

net-adds-1-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of one (1) year (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

06

net-adds-2-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of two (2) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

07

net-adds-3-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of three (3) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

08

net-adds-4-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of four (4) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

09

net-adds-5-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of five (5) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

10

net-adds-6-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of six (6) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

11

net-adds-7-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of seven (7) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

12

net-adds-8-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of eight (8) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

13

net-adds-9-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of nine (9) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

14

net-adds-10-yr

number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of ten (10) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends.

15

net-renews-1-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of one (1) year (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

16

net-renews-2-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of two (2) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

17

net-renews-3-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of three (3) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

18

net-renews-4-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of four (4) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

19

net-renews-5-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of five (5) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

20

net-renews-6-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of six (6) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

21

net-renews-7-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of seven (7) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

22

net-renews-8-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of eight (8) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

23

net-renews-9-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of nine (9) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

24

net-renews-10-yr

number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of ten (10) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends.

25

transfer-gaining-successful

number of domain transfers initiated by this registrar that were successfully completed (either explicitly or automatically approved) and not deleted within the transfer grace period. A transaction must be reported in the month the transfer grace period ends.

26

transfer-gaining-nacked

number of domain transfers initiated by this registrar that were rejected (e.g., EPP transfer op=“reject”) by the other registrar

27

transfer-losing-successful

number of domain transfers initiated by another registrar that were successfully completed (either explicitly or automatically approved)

28

transfer-losing-nacked

number of domain transfers initiated by another registrar that this registrar rejected (e.g., EPP transfer op=“reject”)

29

transfer-disputed-won

number of transfer disputes in which this registrar prevailed (reported in the month where the determination happened)

30

transfer-disputed-lost

number of transfer disputes this registrar lost (reported in the month where the determination happened)

31

transfer-disputed-nodecision

number of transfer disputes involving this registrar with a split or no decision (reported in the month where the determination happened)

32

deleted-domains-grace

domains deleted within the add grace period (does not include names deleted while in EPP pendingCreate status). A deletion must be reported in the month the name is purged.

33

deleted-domains-nograce

domains deleted outside the add grace period (does not include names deleted while in EPP pendingCreate status). A deletion must be reported in the month the name is purged.

34

restored-domains

domain names restored during reporting period

35

restored-noreport

total number of restored names for which a restore report is required by the registry, but the registrar failed to submit it

36

agp-exemption-requests

total number of AGP (add grace period) exemption requests

37

agp-exemptions-granted

total number of AGP (add grace period) exemption requests granted

38

agp-exempted-domains

total number of names affected by granted AGP (add grace period) exemption requests

39

attempted-adds

number of attempted (both successful and failed) domain name create commands

 

The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. The last line of each report shall include totals for each column across all registrars; the first field of this line shall read “Totals” while the second field shall be left empty in that line. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180.

 

2.              Registry Functions Activity Report. This report shall be compiled in a comma separated-value formatted file as specified in RFC 4180. The file shall be named “gTLD-activity-yyyymm.csv”, where “gTLD” is the gTLD name; in case of an IDN-TLD, the A-label shall be used; “yyyymm” is the year and month being reported. The file shall contain the following fields:

Field #

Field Name

Description

01

operational-registrars

number of operational registrars in the production system at the end of the reporting period

02

zfa-passwords

number of active zone file access passwords at the end of the reporting period; “CZDS” may be used instead of the number of active zone file access passwords, if the Centralized Zone Data Service (CZDS) is used to provide the zone file to the end user

03

whois-43-queries

number of WHOIS (port-43) queries responded during the reporting period

04

web-whois-queries

number of Web-based Whois queries responded during the reporting period, not including searchable Whois

05

searchable-whois-queries

number of searchable Whois queries responded during the reporting period, if offered

06

dns-udp-queries-received

number of DNS queries received over UDP transport during the reporting period

07

dns-udp-queries-responded

number of DNS queries received over UDP transport that were responded during the reporting period

08

dns-tcp-queries-received

number of DNS queries received over TCP transport during the reporting period

09

dns-tcp-queries-responded

number of DNS queries received over TCP transport that were responded during the reporting period

10

srs-dom-check

number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period

11

srs-dom-create

number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period

12

srs-dom-delete

number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period

13

srs-dom-info

number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period

14

srs-dom-renew

number of SRS (EPP and any other interface) domain name “renew” requests responded during the reporting period

15

srs-dom-rgp-restore-report

number of SRS (EPP and any other interface) domain name RGP “restore” requests delivering a restore report responded during the reporting period

16

srs-dom-rgp-restore-request

number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period

17

srs-dom-transfer-approve

number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period

18

srs-dom-transfer-cancel

number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period

19

srs-dom-transfer-query

number of SRS (EPP and any other interface) domain name “transfer” requests to query about a transfer responded during the reporting period

20

srs-dom-transfer-reject

number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period

21

srs-dom-transfer-request

number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period

22

srs-dom-update

number of SRS (EPP and any other interface) domain name “update” requests (not including RGP restore requests) responded during the reporting period

23

srs-host-check

number of SRS (EPP and any other interface) host “check” requests responded during the reporting period

24

srs-host-create

number of SRS (EPP and any other interface) host “create” requests responded during the reporting period

25

srs-host-delete

number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period

26

srs-host-info

number of SRS (EPP and any other interface) host “info” requests responded during the reporting period

27

srs-host-update

number of SRS (EPP and any other interface) host “update” requests responded during the reporting period

28

srs-cont-check

number of SRS (EPP and any other interface) contact “check” requests responded during the reporting period

29

srs-cont-create

number of SRS (EPP and any other interface) contact “create” requests responded during the reporting period

30

srs-cont-delete

number of SRS (EPP and any other interface) contact “delete” requests responded during the reporting period

31

srs-cont-info

number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period

32

srs-cont-transfer-approve

number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period

33

srs-cont-transfer-cancel

number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period

34

srs-cont-transfer-query

number of SRS (EPP and any other interface) contact “transfer” requests to query about a transfer responded during the reporting period

35

srs-cont-transfer-reject

number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period

36

srs-cont-transfer-request

number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period

37

srs-cont-update

number of SRS (EPP and any other interface) contact “update” requests responded during the reporting period

 

The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180.

For gTLDs that are part of a single-instance Shared Registry System, the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system.


SPECIFICATION 4

REGISTRATION DATA PUBLICATION SERVICES

1.              Registration Data Directory Services. Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based Directory Service at <whois.nic.TLD> providing free public query-based access to at least the following elements in the following format. ICANN reserves the right to specify alternative formats and protocols, and upon such specification, the Registry Operator will implement such alternative specification as soon as reasonably practicable.

Registry Operator shall implement a new standard supporting access to domain name registration data (SAC 051) no later than one hundred thirty-five (135) days after it is requested by ICANN if: 1) the IETF produces a standard (i.e., it is published, at least, as a Proposed Standard RFC as specified in RFC 2026); and 2) its implementation is commercially reasonable in the context of the overall operation of the registry.

1.1.         The format of responses shall follow a semi-free text format outline below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.

1.2.         Each data object shall be represented as a set of key/value pairs, with lines beginning with keys, followed by a colon and a space as delimiters, followed by the value.

1.3.         For fields where more than one value exists, multiple key/value pairs with the same key shall be allowed (for example to list multiple name servers). The first key/value pair after a blank line should be considered the start of a new record, and should be considered as identifying that record, and is used to group data, such as hostnames and IP addresses, or a domain name and registrant information, together.

1.4.         The fields specified below set forth the minimum output requirements. Registry Operator may output data fields in addition to those specified below, subject to approval by ICANN, which approval shall not be unreasonably withheld.

1.5.         Domain Name Data:

1.5.1      Query format: whois EXAMPLE.TLD

1.5.2      Response format:

Domain Name: EXAMPLE.TLD
Domain ID: D1234567-TLD
WHOIS Server: whois.example.tld
Referral URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 5555555
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.6.         Registrar Data:

1.6.1      Query format: whois “registrar Example Registrar, Inc.”

1.6.2      Response format:

Registrar Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.7.         Nameserver Data:

1.7.1      Query format: whois “nameserver (nameserver name)”, or whois “nameserver (IP Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.

1.7.2      Response format:

Server Name: NS1.EXAMPLE.TLD
IP Address: 192.0.2.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.8.         The format of the following data fields: domain status, individual and organizational names, address, street, city, state/province, postal code, country, telephone and fax numbers (the extension will be provided as a separate field as shown above), email addresses, date and times should conform to the mappings specified in EPP RFCs 5730-5734 so that the display of this information (or values return in WHOIS responses) can be uniformly processed and understood.

1.9.         In order to be compatible with ICANN’s common interface for WHOIS (InterNIC), WHOIS output shall be in the format outline above.

1.10.      Searchability. Offering searchability capabilities on the Directory Services is optional but if offered by the Registry Operator it shall comply with the specification described in this section.

1.10.1  Registry Operator will offer searchability on the web-based Directory Service.

1.10.2  Registry Operator will offer partial match capabilities, at least, on the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.).

1.10.3  Registry Operator will offer exact-match capabilities, at least, on the following fields: Registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).

1.10.4  Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.

1.10.5  Search results will include domain names matching the search criteria.

1.10.6  Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws or policies.

1.11.      Registry Operator shall provide a link on the primary website for the TLD (i.e., the website provided to ICANN for publishing on the ICANN website) to a web page designated by ICANN containing WHOIS policy and educational materials.

2.              Zone File Access

2.1.         Third-Party Access

2.1.1      Zone File Access Agreement. Registry Operator will enter into an agreement with any Internet user, which will allow such user to access an Internet host server or servers designated by Registry Operator and download zone file data. The agreement will be standardized, facilitated and administered by a Centralized Zone Data Access Provider, which may be ICANN or an ICANN designee (the “CZDA Provider”). Registry Operator (optionally through the CZDA Provider) will provide access to zone file data per Section 2.1.3 of this Specification and do so using the file format described in Section 2.1.4 of this Specification. Notwithstanding the foregoing, (a) the CZDA Provider may reject the request for access of any user that does not satisfy the credentialing requirements in Section 2.1.2 below; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 2.1.2 below or where Registry Operator reasonably believes will violate the terms of Section 2.1.5 below; and, (c) Registry Operator may revoke access of any user if Registry Operator has evidence to support that the user has violated the terms of Section 2.1.5 below.

2.1.2      Credentialing Requirements. Registry Operator, through the facilitation of the CZDA Provider, will request each user to provide it with information sufficient to correctly identify and locate the user. Such user information will include, without limitation, company name, contact name, address, telephone number, facsimile number, email address and IP address.

2.1.3      Grant of Access. Each Registry Operator (optionally through the CZDA Provider) will provide the Zone File SFTP (or other Registry supported) service for an ICANN-specified and managed URL (specifically, <TLD>.zda.icann.org where <TLD> is the TLD for which the registry is responsible) for the user to access the Registry’s zone data archives. Registry Operator will grant the user a non-exclusive, nontransferable, limited right to access Registry Operator’s (optionally CZDA Provider’s) Zone File hosting server, and to transfer a copy of the top-level domain zone files, and any associated cryptographic checksum files no more than once per 24 hour period using SFTP, or other data transport and access protocols that may be prescribed by ICANN. For every zone file access server, the zone files are in the top-level directory called <zone>.zone.gz, with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify downloads. If the Registry Operator (or the CZDA Provider) also provides historical data, it will use the naming pattern <zone>-yyyymmdd.zone.gz, etc.

2.1.4      File Format Standard. Registry Operator (optionally through the CZDA Provider) will provide zone files using a subformat of the standard Master File format as originally defined in RFC 1035, Section 5, including all the records present in the actual zone used in the public DNS. Sub-format is as follows:

1.              Each record must include all fields in one line as: <domain-name> <TTL> <class> <type> <RDATA>.

2.              Class and Type must use the standard mnemonics and must be in lower case.

3.              TTL must be present as a decimal integer.

4.              Use of \X and \DDD inside domain names is allowed.

5.              All domain names must be in lower case.

6.              Must use exactly one tab as separator of fields inside a record.

7.              All domain names must be fully qualified.

8.              No $ORIGIN directives.

9.              No use of “@” to denote current origin.

10.          No use of “blank domain names” at the beginning of a record to continue the use of the domain name in the previous record.

11.          No $INCLUDE directives.

12.          No $TTL directives.

13.          No use of parentheses, e.g., to continue the list of fields in a record across a line boundary.

14.          No use of comments.

15.          No blank lines.

16.          The SOA record should be present at the top and (duplicated at) the end of the zone file.

17.          With the exception of the SOA record, all the records in a file must be in alphabetical order.

18.          One zone per file. If a TLD divides its DNS data into multiple zones, each zone goes into a separate file named as above, with all the files combined using tar into a file called <tld>.zone.tar.

2.1.5      Use of Data by User. Registry Operator will permit user to use the zone file for lawful purposes; provided that (a) user takes all reasonable steps to protect against unauthorized access to, use of, and disclosure of the data, and (b) under no circumstances will Registry Operator be required or permitted to allow user to use the data to (i) allow, enable or otherwise support any marketing activities to entities other than the user’s existing customers, regardless of the medium used (such media include but are not limited to transmission by e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts of mass unsolicited, commercial advertising or solicitations to entities), (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrar, or (iii) interrupt, disrupt or interfere in the normal business operations of any registrant.

2.1.6      Term of Use. Registry Operator, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Registry Operator will allow users to renew their Grant of Access.

2.1.7      No Fee for Access. Registry Operator will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

2.2.         Co-operation

2.2.1      Assistance. Registry Operator will co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by permitted users as contemplated under this Schedule.

2.3.         ICANN Access. Registry Operator shall provide bulk access to the zone files for the TLD to ICANN or its designee on a continuous basis in the manner ICANN may reasonably specify from time to time. Access will be provided at least daily. Zone files will include SRS data committed as close as possible to 00:00:00 UTC.

2.4.         Emergency Operator Access. Registry Operator shall provide bulk access to the zone files for the TLD to the Emergency Operators designated by ICANN on a continuous basis in the manner ICANN may reasonably specify from time to time.

3.              Bulk Registration Data Access to ICANN

3.1.         Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services as well as to facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

3.1.1      Contents. Registry Operator will provide, at least, the following data for all registered domain names: domain name, domain name repository object id (roid), Registrar ID (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars, at least, it will provide: registrar name, registrar id (IANA ID), hostname of registrar Whois server, and URL of registrar.

3.1.2      Format. The data will be provided in the format specified in Specification 2 for Data Escrow (including encryption, signing, etc.) but including only the fields mentioned in the previous section, i.e., the file will only contain Domain and Registrar objects with the fields mentioned above. Registry Operator has the option to provide a full deposit file instead as specified in Specification 2.

3.1.3      Access. Registry Operator will have the file(s) ready for download as of 00:00:00 UTC on the day designated for retrieval by ICANN. The file(s) will be made available for download by SFTP, though ICANN may request other means in the future.

3.2.         Exceptional Access to Thick Registration Data. In case of a registrar failure, deaccreditation, court order, etc. that prompts the temporary or definitive transfer of its domain names to another registrar, at the request of ICANN, Registry Operator will provide ICANN with up-to-date data for the domain names of the losing registrar. The data will be provided in the format specified in Specification 2 for Data Escrow. The file will only contain data related to the domain names of the losing registrar. Registry Operator will provide the data as soon as commercially practicable, but in no event later than five (5) calendar days following ICANN’s request. Unless otherwise agreed by Registry Operator and ICANN, the file will be made available for download by ICANN in the same manner as the data specified in Section 3.1 of this Specification.

4.              Registration Data Access Protocol (RDAP) Global Amendment. Registry Operator acknowledges and agrees that the Global Amendment to the Base Registry Agreement (defined as the registry agreement set forth at https://www.icann.org/resources/pages/registries/registries-agreements-en, as may be amended from time to time) implementing Registration Data Access Protocol (“RDAP”), including adding new terms related to Registration Data Directory Services (such amendment, the “RDAP Global Amendment”), shall, in both form and substance, be incorporated in and applicable to this Agreement upon the effective date of the RDAP Global Amendment (such date, the “RDAP Global Amendment Effective Date”). ICANN shall give Registry Operator sixty (60) days’ prior written notice of the anticipated RDAP Global Amendment Effective Date.

As soon as reasonably practicable following such notice, ICANN shall deliver to Registry Operator a draft amendment revising the terms of this Agreement as necessary to incorporate the terms of the RDAP Global Amendment (the “Registry Agreement Amendment”). Both parties shall use commercially reasonable efforts to finalize the terms of the Registry Agreement Amendment prior to the RDAP Global Amendment Effective Date. Following the RDAP Global Amendment Effective Date and until the effective date of the Registry Agreement Amendment, Registry Operator shall comply with the terms of the RDAP Global Amendment, unless compliance with any term or provision thereof is waived by ICANN in writing.

 


SPECIFICATION 5

SCHEDULE OF RESERVED NAMES

Except to the extent that ICANN otherwise expressly authorizes in writing, and subject to the terms and conditions of this Specification, Registry Operator shall reserve the following labels from initial (i.e., other than renewal) registration within the TLD. If using self-allocation, the Registry Operator must show the registration in the RDDS. In the case of IDN names (as indicated below), IDN variants will be identified according to the registry operator IDN registration policy, where applicable.

1.              Example. The ASCII label “EXAMPLE” shall be withheld from registration or allocated to Registry Operator at the second level and at all other levels within the TLD at which Registry Operator offers registrations (such second level and all other levels are collectively referred to herein as, “All Levels”). Such label may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, such withheld or allocated label shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such name without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 7.2(c) of the Agreement.

2.              Two Character Labels. All two character labels that were previously reserved by Registry Operator pursuant to prior registry agreements between Registry Operator and ICANN may be allocated through ICANN-accredited registrars, subject to the following:

2.1.         Registration Policy: For all new registrations after the Effective Date, Registry Operator must include a provision in its publicly available registration policy requiring a representation that the registrant of a letter/letter two-character ASCII label will take steps to ensure against misrepresenting or falsely implying that the registrant or its business is affiliated with a government or country-code manager if such affiliation, sponsorship or endorsement does not exist.

2.2.         Post-Registration Complaint Investigation. Registry Operator shall take reasonable steps to investigate and respond to any reports from governmental agencies and ccTLD operators of conduct that causes confusion with the corresponding country code in connection with the use of a letter/letter two-character ACSCII domain. In responding to such reports, Registry Operator will not be required to take any action in contravention of applicable law.

3.              Reservations for Registry Operations.

3.1.         The following ASCII labels must be withheld from registration or allocated to Registry Operator at All Levels for use in connection with the operation of the registry for the TLD: WWW, RDDS and WHOIS. The following ASCII label must be allocated to Registry Operator upon delegation into the root zone at All Levels for use in connection with the operation of the registry for the TLD: NIC. Registry Operator may activate WWW, RDDS and WHOIS in the DNS, but must activate NIC in the DNS, as necessary for the operation of the TLD (in accordance with the provisions of Exhibit A, the ASCII label NIC must be provisioned in the DNS as a zone cut using NS resource records). None of WWW, RDDS, WHOIS or NIC may be released or registered to any person (other than Registry Operator) or third party. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD all such withheld or allocated names shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 7.2(c) of the Agreement. Such domains shall be identified by Registrar ID 9999.

3.1.1      If Exhibit A to the Agreement specifically provides that Registry Operator may offer registration of IDNs, Registry Operator may also activate a language-specific translation or transliteration of the term “NIC” or an abbreviation for the translation of the term “Network Information Center” in the DNS in accordance with Registry Operator’s IDN Tables and IDN Registration Rules. Such translation, transliteration or abbreviation may be reserved by Registry Operator and used in addition to the label NIC to provide any required registry functions. For the avoidance of doubt, Registry Operator is required to activate the ASCII label NIC pursuant to Section 3.1 of this Specification 5.

3.2.         [RESERVED]

3.3.         Registry Operator may withhold from registration or allocate to Registry Operator names (including their IDN variants, where applicable) at All Levels in accordance with Section 3.1(c)(i)(B) of the Agreement. Such names may not be activated in the DNS, but may be released for registration to Registry Operator or another person or entity at Registry Operator’s discretion, subject to compliance with all the terms of this Agreement, including applicable RPMs set forth in Specification 7. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, all such names that remain withheld from registration or allocated to Registry Operator shall be transferred as specified by ICANN. Upon ICANN’s request, Registry Operator shall provide a listing of all names withheld or allocated to Registry Operator pursuant to Section 3.1(c)(i)(B) of the Agreement. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 7.2(a) of the Agreement.

3.4.         Registry Operator shall allocate the domain name “icann-sla-monitoring.<tld>“ to the ICANN testing registrar (as such registrar is described in Section 8.2 of Specification 10). If such domain name is not available for registration in the TLD or is otherwise inconsistent with the registration policies of the TLD, Registry Operator may allocate a different domain name to the ICANN testing registrar in consultation with ICANN. The allocation of any such alternative domain name will be communicated to ICANN following such consultation. The allocation of the domain name “icann-sla-monitoring.<tld>” to the ICANN testing registrar will not be considered a Transaction for purposes of Section 7.2(c) of the Agreement.

4.              Country and Territory Names. The country and territory names (including their IDN variants, where applicable) contained in the following internationally recognized lists shall be withheld from registration or allocated to Registry Operator at All Levels:

4.1.         the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union <http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm>;

4.2.         the United Nations Group of Experts on Geographical Names, Technical Reference Manual for the Standardization of Geographical Names, Part III Names of Countries of the World; and

4.3.         the list of United Nations member states in 6 official United Nations languages prepared by the Working Group on Country Names of the United Nations Conference on the Standardization of Geographical Names;

provided, that the reservation of specific country and territory names (including their IDN variants according to the registry operator IDN registration policy, where applicable) may be released to the extent that Registry Operator reaches agreement with the applicable government(s). Registry Operator must not activate such names in the DNS; provided, that Registry Operator may propose the release of these reservations, subject to review by ICANN’s Governmental Advisory Committee and approval by ICANN. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, all such names that remain withheld from registration or allocated to Registry Operator shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 7.2(c) of the Agreement.

5.         [RESERVED]

6.         [RESERVED]


SPECIFICATION 6

REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS

1.              Standards Compliance

1.1.         DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 3226, 3596, 3597, 4343, 5966 and 6891. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., “xn--ndk061n”).

1.2.         EPP. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the provisioning and management of domain names using the Extensible Provisioning Protocol (EPP) in conformance with RFCs 5910, 5730, 5731, 5732 (if using host objects), 5733 and 5734. If Registry Operator implements Registry Grace Period (RGP), it will comply with RFC 3915 and its successors. If Registry Operator requires the use of functionality outside the base EPP RFCs, Registry Operator must document EPP extensions in Internet-Draft format following the guidelines described in RFC 3735. Registry Operator will provide and update the relevant documentation of all the EPP Objects and Extensions supported to ICANN prior to deployment.

1.3.         DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Operator shall publish its DPS following the format described in RFC 6841. DNSSEC validation must be active and use the IANA DNS Root Key Signing Key set (available at https://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s Registry Services making use of data obtained via DNS responses.

1.4.         IDN. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registry Operator shall comply with the ICANN IDN Guidelines at <http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices.

1.5.         IPv6. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91 and the recommendations and considerations described in RFC 4472. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g., Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six (6) months after receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS over IPv6.

1.6.         IANA Rootzone Database. In order to ensure that authoritative information about the TLD remains publicly available, Registry Operator shall submit a change request to the IANA functions operator updating any outdated or inaccurate DNS or WHOIS records of the TLD. Registry Operator shall use commercially reasonable efforts to submit any such change request no later than seven (7) calendar days after the date any such DNS or WHOIS records becomes outdated or inaccurate. Registry Operator must submit all change requests in accordance with the procedures set forth at <http://www.iana.org/domains/root>.

1.7.         Network Ingress Filtering. Registry Operator shall implement network ingress filtering checks for its Registry Services as described in BCP 38 and BCP 84, which ICANN will also implement.

2.              Registry Services

2.1.         Registry Services. “Registry Services” are, for purposes of the Agreement, defined as the following: (a) those services that are operations of the registry critical to the following tasks: the receipt of data from registrars concerning registrations of domain names and name servers; provision to registrars of status information relating to the zone servers for the TLD; dissemination of TLD zone files; operation of the registry DNS servers; and dissemination of contact and other information concerning domain name server registrations in the TLD as required by this Agreement; (b) other products or services that the Registry Operator is required to provide because of the establishment of a Consensus Policy as defined in Specification 1; (c) any other products or services that only a registry operator is capable of providing, by reason of its designation as the registry operator; and (d) material changes to any Registry Service within the scope of (a), (b) or (c) above.

2.2.         Wildcard Prohibition. For domain names which are either not registered, or the registrant has not supplied valid records such as NS records for listing in the DNS zone file, or their status does not allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs 1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using redirection within the DNS by the Registry is prohibited. When queried for such domain names the authoritative name servers must return a “Name Error” response (also known as NXDOMAIN), RCODE 3 as described in RFC 1035 and related RFCs. This provision applies for all DNS zone files at all levels in the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services) maintains data, arranges for such maintenance, or derives revenue from such maintenance.

3.              Registry Continuity

3.1.         High Availability. Registry Operator will conduct its operations using network and geographically diverse, redundant servers (including network-level redundancy, end-node level redundancy and the implementation of a load balancing scheme where applicable) to ensure continued operation in the case of technical failure (widespread or local), or an extraordinary occurrence or circumstance beyond the control of the Registry Operator. Registry Operator’s emergency operations department shall be available at all times to respond to extraordinary occurrences.

3.2.         Extraordinary Event. Registry Operator will use commercially reasonable efforts to restore the critical functions of the registry within twenty-four (24) hours after the termination of an extraordinary event beyond the control of the Registry Operator and restore full system functionality within a maximum of forty-eight (48) hours following such event, depending on the type of critical function involved. Outages due to such an event will not be considered a lack of service availability.

3.3.         Business Continuity. Registry Operator shall maintain a business continuity plan, which will provide for the maintenance of Registry Services in the event of an extraordinary event beyond the control of the Registry Operator or business failure of Registry Operator, and may include the designation of a Registry Services continuity provider. If such plan includes the designation of a Registry Services continuity provider, Registry Operator shall provide the name and contact information for such Registry Services continuity provider to ICANN. In the case of an extraordinary event beyond the control of the Registry Operator where the Registry Operator cannot be contacted, Registry Operator consents that ICANN may contact the designated Registry Services continuity provider, if one exists. Registry Operator shall conduct Registry Services Continuity testing at least once per year.

4.              Abuse Mitigation

4.1.         Abuse Contact. Registry Operator shall provide to ICANN and publish on its website its accurate contact details including a valid email and mailing address as well as a primary contact for handling inquiries related to malicious conduct in the TLD, and will provide ICANN with prompt notice of any changes to such contact details.

4.2.         Malicious Use of Orphan Glue Records. Registry Operator shall take action to remove orphan glue records (as defined at http://www.icann.org/en/committees/security/sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct.

5.              Supported Initial and Renewal Registration Periods

5.1.         Initial Registration Periods. Initial registrations of registered names may be made in the registry in one (1) year increments for up to a maximum of ten (10) years. For the avoidance of doubt, initial registrations of registered names may not exceed ten (10) years.

5.2.         Renewal Periods. Renewal of registered names may be made in one (1) year increments for up to a maximum of ten (10) years. For the avoidance of doubt, renewal of registered names may not extend their registration period beyond ten (10) years from the time of the renewal.

6.              [RESERVED]


SPECIFICATION 7

MINIMUM REQUIREMENTS FOR RIGHTS PROTECTION MECHANISMS

1.              Rights Protection Mechanisms. Registry Operator may develop and implement rights protection mechanisms (“RPMs”) that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Registry Operator will include all RPMS required by this Specification 7 and any additional RPMs developed and implemented by Registry Operator in the registry-registrar agreement entered into by ICANN-accredited registrars authorized to register names in the TLD.

2.              Dispute Resolution Mechanisms. Registry Operator will comply with the following dispute resolution mechanisms as they may be revised from time to time:

a.              the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN (posted at http://www.icann.org/en/resources/registries/pddrp and http://www.icann.org/en/resources/registries/rrdrp, respectively). Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 6.1(c) of the Agreement) following a determination by any PDDRP panel or RRDRP and to be bound by any such determination; and

b.              the Uniform Rapid Suspension system (“URS”) adopted by ICANN (posted at http://www.icann.org/en/resources/registries/urs), including the implementation of determinations issued by URS examiners.


SPECIFICATION 8

[INTENTIONALLY OMITTED]


SPECIFICATION 9

REGISTRY OPERATOR CODE OF CONDUCT

1.              In connection with the operation of the registry for the TLD, Registry Operator will not, and will not allow any parent, subsidiary, Affiliate, subcontractor or other related entity, to the extent such party is engaged in the provision of Registry Services with respect to the TLD (each, a “Registry Related Party”), to:

a.              directly or indirectly show any preference or provide any special consideration to any registrar with respect to operational access to registry systems and related registry services, unless comparable opportunities to qualify for such preferences or considerations are made available to all registrars on substantially similar terms and subject to substantially similar conditions;

b.              register domain names in its own right, except for names registered through an ICANN accredited registrar; provided, however, that Registry Operator may reserve names from registration pursuant to Section 3.1(c)(i)(B) of the Agreement;

c.              register names in the TLD or sub-domains of the TLD based upon proprietary access to information about searches or resolution requests by consumers for domain names not yet registered (commonly known as, “front-running”); or

d.              allow any Affiliated registrar to disclose Personal Data about registrants to Registry Operator or any Registry Related Party, except as reasonably necessary for the management and operations of the TLD, unless all unrelated third parties (including other registry operators) are given equivalent access to such user data on substantially similar terms and subject to substantially similar conditions.

2.              If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will, or will cause such Registry Related Party to, ensure that such services are offered through a legal entity separate from Registry Operator, and maintain separate books of accounts with respect to its registrar or registrar-reseller operations.

3.              If Registry Operator or a Registry Related Party also operates as a provider of registrar or registrar-reseller services, Registry Operator will conduct internal reviews at least once per calendar year to ensure compliance with this Code of Conduct. Within twenty (20) calendar days following the end of each calendar year, Registry Operator will provide the results of the internal review, along with a certification executed by an executive officer of Registry Operator certifying as to Registry Operator’s compliance with this Code of Conduct, via email to an address to be provided by ICANN. (ICANN may specify in the future the form and contents of such reports or that the reports be delivered by other reasonable means.) Registry Operator agrees that ICANN may publicly post such results and certification.

4.              Nothing set forth herein shall: (i) limit ICANN from conducting investigations of claims of Registry Operator’s non-compliance with this Code of Conduct; or (ii) provide grounds for Registry Operator to refuse to cooperate with ICANN investigations of claims of Registry Operator’s non-compliance with this Code of Conduct.

5.              Nothing set forth herein shall limit the ability of Registry Operator or any Registry Related Party, to enter into arms-length transactions in the ordinary course of business with a registrar or reseller with respect to products and services unrelated in all respects to the TLD.

6.              Registry Operator may request an exemption to this Code of Conduct, and such exemption may be granted by ICANN in ICANN’s reasonable discretion, if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (i) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator for the exclusive use of Registry Operator or its Affiliates, (ii) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (iii) application of this Code of Conduct to the TLD is not necessary to protect the public interest.

 


SPECIFICATION 10

REGISTRY PERFORMANCE SPECIFICATIONS

1.              Definitions

1.1.         DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.

1.2.         DNSSEC proper resolution. There is a valid DNSSEC chain of trust from the root trust anchor to a particular domain name, e.g., a TLD, a domain name registered under a TLD, etc.

1.3.         EPP. Refers to the Extensible Provisioning Protocol as specified in RFC 5730 and related RFCs.

1.4.         IP address. Refers to IPv4 or IPv6 addresses without making any distinction between the two. When there is need to make a distinction, IPv4 or IPv6 is used.

1.5.         Probes. Network hosts used to perform (DNS, EPP, etc.) tests (see below) that are located at various global locations.

1.6.         RDDS. Registration Data Directory Services refers to the collective of WHOIS and Web-based WHOIS services as defined in Specification 4 of this Agreement.

1.7.         RTT. Round-Trip Time or RTT refers to the time measured from the sending of the first bit of the first packet of the sequence of packets needed to make a request until the reception of the last bit of the last packet of the sequence needed to receive the response. If the client does not receive the whole sequence of packets needed to consider the response as received, the request will be considered unanswered.

1.8.         SLR. Service Level Requirement is the level of service expected for a certain parameter being measured in a Service Level Agreement (SLA).

2.              Service Level Agreement Matrix

 

Parameter

SLR (monthly basis)

DNS

DNS service availability

0 min downtime = 100% availability

 

DNS name server availability

£ 432 min of downtime (» 99%)

 

TCP DNS resolution RTT

£ 1500 ms, for at least 95% of the queries

 

UDP DNS resolution RTT

£ 500 ms, for at least 95% of the queries

 

DNS update time

£ 60 min, for at least 95% of the probes

RDDS

RDDS availability

£ 864 min of downtime (» 98%)

 

RDDS query RTT

£ 2000 ms, for at least 95% of the queries

 

RDDS update time

£ 60 min, for at least 95% of the probes

EPP

EPP service availability

£ 864 min of downtime (» 98%)

 

EPP session-command RTT

£ 4000 ms, for at least 90% of the commands

 

EPP query-command RTT

£ 2000 ms, for at least 90% of the commands

 

EPP transform-command RTT

£ 4000 ms, for at least 90% of the commands

 

Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. However, note that there is no provision for planned outages or similar periods of unavailable or slow service; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLA purposes.

3.              DNS

3.1.         DNS service availability. Refers to the ability of the group of listed-as-authoritative name servers of a particular domain name (e.g., a TLD), to answer DNS queries from DNS probes. For the service to be considered available at a particular moment, at least, two of the delegated name servers registered in the DNS must have successful results from “DNS tests” to each of their public-DNS registered “IP addresses” to which the name server resolves. If 51% or more of the DNS testing probes see the service as unavailable during a given time, the DNS service will be considered unavailable.

3.2.         DNS name server availability. Refers to the ability of a public-DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user. All the public DNS-registered “IP address” of all name servers of the domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get undefined/unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unavailable.

3.3.         UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.4.         TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered undefined.

3.5.         DNS resolution RTT. Refers to either “UDP DNS resolution RTT” or “TCP DNS resolution RTT”.

3.6.         DNS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, until the name servers of the parent domain name answer “DNS queries” with data consistent with the change made. This only applies for changes to DNS information.

3.7.         DNS test. Means one non-recursive DNS query sent to a particular “IP address” (via UDP or TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor. The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will be considered unanswered. The possible results to a DNS test are: a number in milliseconds corresponding to the “DNS resolution RTT” or, undefined/unanswered.

3.8.         Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-DNS registered “IP addresses” of the name servers of the domain name being monitored. If a “DNS test” result is undefined/unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.

3.9.         Collating the results from DNS probes. The minimum number of active testing probes to consider a measurement valid is 20 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

3.10.      Distribution of UDP and TCP queries. DNS probes will send UDP or TCP “DNS test” approximating the distribution of these queries.

3.11.      Placement of DNS probes. Probes for measuring DNS parameters shall be placed as near as possible to the DNS resolvers on the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

4.              RDDS

4.1.         RDDS availability. Refers to the ability of all the RDDS services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the RDDS testing probes see any of the RDDS services as unavailable during a given time, the RDDS will be considered unavailable.

4.2.         WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the WHOIS response. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

4.3.         Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If Registry Operator implements a multiple-step process to get to the information, only the last step shall be measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

4.4.         RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”.

4.5.         RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the RDDS services reflect the changes made.

4.6.         RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the RDDS services. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDDS test are: a number in milliseconds corresponding to the RTT or undefined/unanswered.

4.7.         Measuring RDDS parameters. Every 5 minutes, RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each RDDS service of the TLD being monitored and make an “RDDS test” to each one. If an “RDDS test” result is undefined/unanswered, the corresponding RDDS service will be considered as unavailable from that probe until it is time to make a new test.

4.8.         Collating the results from RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

4.9.         Placement of RDDS probes. Probes for measuring RDDS parameters shall be placed inside the networks with the most users across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

5.              EPP

5.1.         EPP service availability. Refers to the ability of the TLD EPP servers as a group, to respond to commands from the Registry accredited Registrars, who already have credentials to the servers. The response shall include appropriate data from the Registry System. An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be considered as unanswered. If 51% or more of the EPP testing probes see the EPP service as unavailable during a given time, the EPP service will be considered unavailable.

5.2.         EPP session-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session. For the logout command it will include packets needed for closing the TCP session. EPP session commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

5.3.         EPP query-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.

5.4.         EPP transform-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP transform commands are those described in section 2.9.3 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered undefined.

5.5.         EPP command RTT. Refers to “EPP session-command RTT”, “EPP query-command RTT” or “EPP transform-command RTT”.

5.6.         EPP test. Means one EPP command sent to a particular “IP address” for one of the EPP servers. Query and transform commands, with the exception of “create”, shall be about existing objects in the Registry System. The response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the “EPP command RTT” or undefined/unanswered.

5.7.         Measuring EPP parameters. Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make an “EPP test”; every time they should alternate between the 3 different types of commands and between the commands inside each category. If an “EPP test” result is undefined/unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.

5.8.         Collating the results from EPP probes. The minimum number of active testing probes to consider a measurement valid is 5 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.

5.9.         Placement of EPP probes. Probes for measuring EPP parameters shall be placed inside or close to Registrars points of access to the Internet across the different geographic regions; care shall be taken not to deploy probes behind high propagation-delay links, such as satellite links.

6.              Emergency Thresholds

The following matrix presents the emergency thresholds that, if reached by any of the services mentioned above for a TLD, would cause the emergency transition of the Registry for the TLD as specified in Section 3.1(c)(ix) of this Agreement.

Critical Function

Emergency Threshold

DNS Service

4-hour total downtime / week

DNSSEC proper resolution

4-hour total downtime / week

EPP

24-hour total downtime / week

RDDS

24-hour total downtime / week

Data Escrow

Reaching any of the criteria for the release of deposits described in Specification 2, Part B, Section 6.2 through Section 6.6.

 

7.              Emergency Escalation

Escalation is strictly for purposes of notifying and investigating possible or potential issues in relation to monitored services. The initiation of any escalation and the subsequent cooperative investigations do not in themselves imply that a monitored service has failed its performance requirements.

Escalations shall be carried out between ICANN and Registry Operators, Registrars and Registry Operator, and Registrars and ICANN. Registry Operators and ICANN must provide said emergency operations departments. Current contacts must be maintained between ICANN and Registry Operators and published to Registrars, where relevant to their role in escalations, prior to any processing of an Emergency Escalation by all related parties, and kept current at all times.

7.1.         Emergency Escalation initiated by ICANN

Upon reaching 10% of the Emergency thresholds as described in Section 6 of this Specification, ICANN’s emergency operations will initiate an Emergency Escalation with the relevant Registry Operator. An Emergency Escalation consists of the following minimum elements: electronic (i.e., email or SMS) and/or voice contact notification to the Registry Operator’s emergency operations department with detailed information concerning the issue being escalated, including evidence of monitoring failures, cooperative trouble-shooting of the monitoring failure between ICANN staff and the Registry Operator, and the commitment to begin the process of rectifying issues with either the monitoring service or the service being monitoring.

7.2.         Emergency Escalation initiated by Registrars

Registry Operator will maintain an emergency operations department prepared to handle emergency requests from registrars. In the event that a registrar is unable to conduct EPP transactions with the registry for the TLD because of a fault with the Registry Service and is unable to either contact (through ICANN mandated methods of communication) the Registry Operator, or the Registry Operator is unable or unwilling to address the fault, the registrar may initiate an emergency escalation to the emergency operations department of ICANN. ICANN then may initiate an emergency escalation with the Registry Operator as explained above.

7.3.         Notifications of Outages and Maintenance

In the event that a Registry Operator plans maintenance, it will provide notice to the ICANN emergency operations department, at least, twenty-four (24) hours ahead of that maintenance. ICANN’s emergency operations department will note planned maintenance times, and suspend Emergency Escalation services for the monitored services during the expected maintenance outage period.

If Registry Operator declares an outage, as per its contractual obligations with ICANN, on services under a service level agreement and performance requirements, it will notify the ICANN emergency operations department. During that declared outage, ICANN’s emergency operations department will note and suspend emergency escalation services for the monitored services involved.

8.              Covenants of Performance Measurement

8.1.         No interference. Registry Operator shall not interfere with measurement Probes, including any form of preferential treatment of the requests for the monitored services. Registry Operator shall respond to the measurement tests described in this Specification as it would to any other request from an Internet user (for DNS and RDDS) or registrar (for EPP).

8.2.         ICANN testing registrar. Registry Operator agrees that ICANN will have a testing registrar used for purposes of measuring the SLRs described above. Registry Operator agrees to not provide any differentiated treatment for the testing registrar other than no billing of the transactions. ICANN shall not use the registrar for registering domain names (or other registry objects) for itself or others, except for the purposes of verifying contractual compliance with the conditions described in this Agreement. Registry Operator shall identify these transactions using Registrar ID 9997.

 

 


SPECIFICATION 11

PUBLIC INTEREST COMMITMENTS

  1. Registry Operator will use only ICANN accredited registrars that are party to the Registrar Accreditation Agreement approved by the ICANN Board of Directors on 27 June 2013 in registering domain names. A list of such registrars shall be maintained by ICANN on ICANN’s website.

 

  1. [RESERVED]

 

  1. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN (posted at http://www.icann.org/en/resources/registries/picdrp), which may be revised in immaterial respects by ICANN from time to time (the “PICDRP”). Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 6.1(c) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination.

 

    1. Registry Operator will include a provision in its Registry-Registrar Agreement that requires Registrars to include in their Registration Agreements a provision prohibiting Registered Name Holders from distributing malware, abusively operating botnets, phishing, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related procedures) consequences for such activities including suspension of the domain name.

 

    1. Registry Operator will periodically conduct a technical analysis to assess whether domains in the TLD are being used to perpetrate security threats, such as pharming, phishing, malware, and botnets. Registry Operator will maintain statistical reports on the number of security threats identified and the actions taken as a result of the periodic security checks. Registry Operator will maintain these reports for the term of the Agreement unless a shorter period is required by law or approved by ICANN, and will provide them to ICANN upon request.

 

    1. Registry Operator will operate the TLD in a transparent manner consistent with general principles of openness and non-discrimination by establishing, publishing and adhering to clear registration policies.

 

    1. Registry Operator of a “Generic String” TLD may not impose eligibility criteria for registering names in the TLD that limit registrations exclusively to a single person or entity and/or that person’s or entity’s “Affiliates” (as defined in Section 7.1(c) of this Agreement). “Generic String” means a string consisting of a word or term that denominates or describes a general class of goods, services, groups, organizations or things, as opposed to distinguishing a specific brand of goods, services, groups, organizations or things from those of others.

 

 SPECIFICATION 12

 

COMMUNITY REGISTRATION POLICIES

 

Registry Operator shall implement and comply with all community registration policies described below and/or attached to this Specification 12. In the event this Specification 12 conflicts with the requirements of any other provision of the Registry Agreement, such other provision of the Registry Agreement shall govern.

 

Contents

 

Part I. TLD Charter

Part II. Delegated Authority

Part III. Description of Sponsored TLD Community

Part IV. Selection of Registrars

 

Part I –TLD Charter

 

.aero Charter

 

The TLD is intended to serve the global aviation community. In accordance with its Articles of Association, the Sponsor will manage the .aero TLD pursuant to the provisions of this charter (“Charter”) and in the interests of the global aviation community. Sponsor will be responsible for establishing registration requirements for the TLD consistent with this Charter.

 

The TLD is restricted to people, entities and government agencies which: (1) provide for and support the efficient, safe, and secure transport of people and cargo by air; and (2) facilitate or perform the necessary transactions to transport people and cargo by air.

 

The Sponsor, with the advice of relevant government and industry representative bodies, may establish stricter requirements for registrants according to the delegation of authority described in Part II of this Specification 12.

 

Without being exhaustive, Sponsor’s policies may permit registrations within the global aviation community by the following:

 

 

The Sponsor may extend the bulleted list above if petitioned to do so by a recognized organization within the global aviation community, provided that any such extension is (1) in accordance with the global aviation community's perceptions about the prevailing scope of the community, and (2) is restricted to people, entities, and government agencies which (a) provide for and support efficient, safe, and secure transport of people and cargo by air, and (b) facilitate or perform the necessary transactions to transport people and cargo by air.

 

Part II

 

Delegated Authority

 

The following areas of responsibility for development of policies for the TLD are delegated to the Sponsor, provided the other provisions of the Agreement and its specifications are followed:

 

1. Establishment of naming conventions to be used in the TLD.

 

2. Restrictions on what types of people or entities may register registered names (which need not be uniform for all names within the TLD), provided the scope of the Charter (Part I) is not exceeded.

 

3. Restrictions on how registered names may be used (which need not be uniform for all names within the TLD), provided the scope of the Charter (Part I) is not exceeded.

 

4. Performance of Eligibility and Name-Selection Services (“ENS Services”), either directly by the Sponsor or by one or more organizations or individuals to which it delegates the responsibility for performing ENS Services, provided that (1) revenues received in connection with ENS Services are used solely to defray the cost of providing ENS Services or otherwise sponsoring the TLD, with allowance for accumulation of reasonable operating reserves, or (2) ENS Services are outsourced on a competitive basis.

 

5. Mechanisms for enforcement of the policies in items 1, 2 and 3, including procedures for cancellation of registrations.

 

6. Mechanisms for resolution of disputes between owners of rights in names (such as trademarks) and registrants that do not supplant ICANN's dispute-resolution policies or remedies that may be available under law

 

7. Functional and performance specifications for, and pricing of, Registry Services providing the minimum requirements specified in Specification 10 are met.

 

8. Matters concerning the operation of the registry for the TLD.

 

9. Selection of ICANN-accredited registrars to act as registrars for the TLD, consistent with Specification 12, Part IV.

 

10. Terms of agreement to be offered by the Registry Operator to ICANN-accredited registrars selected by Sponsor pursuant to Specification 12, Part IV, including provisions for fair treatment by the Registry Operator of those registrars.

 

11. Practices and performance of ICANN-accredited registrars selected by Sponsor pursuant to Specification 12, Part IV with respect to registered names and their registration.

 

12. Terms of agreement between Sponsor and registrants and registrars and registrants under which registered names are registered.

 

13. Uses and practices by registrants with respect to registered names.

 

14. Provisions for publication of registry and registrar data consistent with the Agreement and registrar accreditation agreements.

 

15. Terms of agreement between or among Sponsor, registrars, other relevant entities and registrants necessary to give effect to the above.

 

Part III

 

Description of TLD Community

 

The TLD is intended to serve the needs of the global aviation community (the “Community”), which includes those people, entities and government agencies which: (1) provide for and support the efficient, safe, and secure transport of people and cargo by air; and (2) facilitate or perform the necessary transactions to transport people and cargo by air.

 

The Sponsor may extend the description of the Community consistent with the Agreement and the Charter.

 

Part IV

 

Selection of Registrars

 

This Specification 12 specifies the criteria for Sponsor’s selection of ICANN-accredited registrars wishing to enter into a Registry-Registrar Agreement to register domain names in the TLD.

 

Sponsor will select from among ICANN-accredited registrars in a manner that promotes the following characteristics in the group of authorized ICANN-accredited registrars:

 

1. Recognition of the specific aspects of the aviation community, that will be supported by the TLD and a willingness to participate in it in that spirit;

 

2. Thorough understanding of the principles and intentions underlying TLD policies, especially as manifested in the domain name management policy and ability to provide ENS Services;

 

3. Dedicated willingness and ability to propagate and enforce these policies in an observant and diligent manner and in accordance with policies and procedures prescribed by the Sponsor;

 

4. Familiarity with the needs of the aviation community and established modes for reflecting these needs in the ENS Services processes;

 

5. Broad geographic distribution and language diversity of registrars;

 

6. Established collaborative contact with one or several associations representing the aviation community in the language and geographical region or sector served by the registrar; and

 

7. Dedicated willingness and ability to act together with the aviation community associations referred to above, in the processing of registration requests.

 

Sponsor will periodically review and as appropriate revise its selection of registrars.