REGISTRY AGREEMENT
This REGISTRY AGREEMENT (this “Agreement”) is entered into as of ___________ (the“Effective Date”) between Internet Corporation for Assigned Names and Numbers, a
California nonprofit public benefit corporation (“ICANN”), and __________, a _____________(“Registry Operator”).
ARTICLE 1.
DELEGATION AND OPERATIONOF TOP–LEVEL DOMAIN; REPRESENTATIONS AND WARRANTIES
1.1
Domain and Designation. The Top-Level Domain to which this Agreement
applies is ____ (the “TLD”). Upon the Effective Date and until the earlier of the expiration of
the Term (as defined in Section 4.1) or the termination of this Agreement pursuant to
Article 4, ICANN designates Registry Operator as the registry operator for the TLD, subject
to the requirements and necessary approvals for delegation of the TLD and entry into theroot-zone.
1.2
Technical Feasibility of String. While ICANN has encouraged and willcontinue to encourage universal acceptance of all top-level domain strings across theInternet, certain top-level domain strings may encounter difficulty in acceptance by ISPs
and webhosters and/or validation by web applications. Registry Operator shall be
responsible for ensuring to its satisfaction the technical feasibility of the TLD string prior toentering into this Agreement.
1.3

Representations and Warranties.
(a)

Registry Operator represents and warrants to ICANN as follows:(i)
all material information provided and statements made in theregistry TLD application, and statements made in writing during thenegotiation of this Agreement, were true and correct in all material respects
at the time made, and such information or statements continue to be true andcorrect in all material respects as of the Effective Date except as otherwise
previously disclosed in writing by Registry Operator to ICANN;(ii)
Registry Operator is duly organized, validly existing and ingood standing under the laws of the jurisdiction set forth in the preamble
hereto, and Registry Operator has all requisite power and authority and has
obtained all necessary approvals to enter into and duly execute and deliver
this Agreement; and(iii)
Registry Operator has delivered to ICANN a duly executed
instrument that secures the funds required to perform registry functions for
the TLD in the event of the termination or expiration of this Agreement (the“Continued Operations Instrument”), and such instrument is a binding1

obligation of the parties thereto, enforceable against the parties thereto inaccordance with its terms.
(b)
ICANN represents and warrants to Registry Operator that ICANN is a
nonprofit public benefit corporation duly organized, validly existing and in good standing
under the laws of the State of California, United States of America. ICANN has all requisite
power and authority and has obtained all necessary corporate approvals to enter into andduly execute and deliver this Agreement.
ARTICLE 2.
COVENANTS OF REGISTRY OPERATOR
Registry Operator covenants and agrees with ICANN as follows:
2.1
Approved Services; Additional Services. Registry Operator shall beentitled to provide the Registry Services described in clauses (a) and (b) of the firstparagraph of Section 2.1 in the Specification 6 attached hereto (“Specification 6”) and suchother 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 fromtime 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 suchapproval, such Additional Services shall be deemed Registry Services under thisAgreement. In its reasonable discretion, ICANN may require an amendment to thisAgreement 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.
2.2
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 Dateand 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 accordancewith the procedure and relate to those topics and subject to those limitations set forth inSpecification 1 attached hereto (“Specification 1”).
2.3
Data Escrow. Registry Operator shall comply with the registry data escrowprocedures set forth in Specification 2 attached hereto (“Specification 2”) within fourteen(14) calendar days after delegation.
2.4
Monthly Reporting. Within twenty (20) calendar days following the end ofeach calendar month, commencing with the first calendar month in which the TLD isdelegated in the root zone, Registry Operator shall deliver to ICANN reports in the format
2set forth in Specification 3 attached hereto (“Specification 3”); provided, however, that if
the TLD is delegated in the root zone after the fifteenth (15th) calendar day of the calendar
month, Registry Operator may defer the delivery of the reports for such first calendar
month and instead deliver to ICANN such month’s reports no later than the time that
Registry Operator is required to deliver the reports for the immediately following calendar
month. Registry Operator must include in the Per-Registrar Transactions Report any
domain name created during pre-delegation testing that has not been deleted as of the timeof delegation (notably but not limited to domains registered by Registrar IDs 9995 and/or9996).
2.5
Publication of Registration Data. Registry Operator shall provide publicaccess to registration data in accordance with Specification 4 attached hereto(“Specification 4”).
2.6
Reserved Names. Except to the extent that ICANN otherwise expressly
authorizes in writing, Registry Operator shall comply with the requirements set forth inSpecification 5 attached hereto (“Specification 5”). Registry Operator may at any time
establish or modify policies concerning Registry Operator’s ability to reserve (i.e., withholdfrom 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 (as defined in
Section 6.1) for purposes of calculating the Registry-level transaction fee to be paid to
ICANN by Registry Operator pursuant to Section 6.1.
2.7
Registry Interoperability and Continuity. Registry Operator shall comply
with the Registry Interoperability and Continuity Specifications as set forth in Specification
6 attached hereto (“Specification 6”).
2.8
Protection of Legal Rights of Third Parties. Registry Operator mustspecify, and comply with, the processes and procedures for launch of the TLD and initial
registration-related and ongoing protection 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 ormodifications to the process and procedures required by Specification 7 following theEffective Date must be approved in advance by ICANN in writing. Registry Operator mustcomply 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 andquasi-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 incontravention of applicable law.

3

2.9

Registrars.

(a)
All domain name registrations in the TLD must be registered throughan ICANN accredited registrar; provided, that Registry Operator need not use a registrar if
it registers names in its own name in order to withhold such names from delegation or use
in accordance with Section 2.6. Subject to the requirements of Specification 11, Registry
Operator must provide non-discriminatory access to Registry Services to all ICANN
accredited registrars that enter into and are in compliance with the registry-registrar
agreement for the TLD; provided that Registry Operator may establish non-discriminatory
criteria for qualification to register names in the TLD that are reasonably related to theproper functioning of the TLD. Registry Operator must use a uniform non-discriminatory
agreement with all registrars authorized to register names in the TLD (the“Registry-Registrar Agreement”). Registry Operator may amend the Registry-Registrar
Agreement from time to time; provided, however, that any material revisions thereto must
be approved by ICANN before any such revisions become effective and binding on any
registrar. Registry Operator will provide ICANN and all registrars authorized to registernames in the TLD at least fifteen (15) calendar days written notice of any revisions to theRegistry-Registrar Agreement before any such revisions become effective and binding on
any registrar. During such period, ICANN will determine whether such proposed revisions
are immaterial, potentially material or material in nature. If ICANN has not provided
Registry Operator with notice of its determination within such fifteen (15) calendar-day
period, ICANN shall be deemed to have determined that such proposed revisions are
immaterial in nature. If ICANN determines, or is deemed to have determined under thisSection 2.9(a), that such revisions are immaterial, then Registry Operator may adopt andimplement such revisions. If ICANN determines such revisions are either material or
potentially material, ICANN will thereafter follow its procedure regarding review andapproval of changes to Registry-Registrar Agreements at<http://www.icann.org/en/resources/registries/rra-amendment-procedure>, and such
revisions may not be adopted and implemented until approved by ICANN.
Notwithstanding the foregoing provisions of this Section 2.9(a), any change to theRegistry-Registrar Agreement that relates exclusively to the fee charged by Registry
Operator to register domain names in the TLD will not be subject to the notice andapproval process specified in this Section 2.9(a), but will be subject to the requirements in
Section 2.10 below.
(b)
If Registry Operator (i) becomes an Affiliate or reseller of an ICANN
accredited registrar, or (ii) subcontracts the provision of any Registry 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 thecontract, 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 treat such contract or related
documents that are appropriately marked as confidential (as required by Section 7.15) as
Confidential Information of Registry Operator in accordance with Section 7.15 (except that
ICANN may disclose such contract and related documents to relevant competition
authorities). ICANN reserves the right, but not the obligation, to refer any such contract,4

related documents, transaction or other arrangement to relevant competition authorities inthe event that ICANN determines that such contract, related documents, transaction orother arrangement might raise significant competition issues under applicable law. If
feasible and appropriate under the circumstances, ICANN will give Registry Operator
advance notice prior to making any such referral to a competition authority.
(c)
For the purposes of this Agreement: (i) “Affiliate” means a person orentity that, directly or indirectly, through one or more intermediaries, or in combination
with one or more other persons or entities, 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 aperson or entity, whether through the ownership of securities, as trustee or executor, byserving as an employee or a member of a board of directors or equivalent governing body,by contract, by credit arrangement or otherwise.
2.10

Pricing for Registry Services.

(a)With respect to initial domain name registrations, Registry Operator
shall provide each ICANN accredited registrar that has executed the Registry-Registrar
Agreement for the TLD advance written notice of any price increase (including as a resultof the elimination of any refunds, rebates, discounts, product tying or other programs
which had the effect of reducing the price charged to registrars, unless such refunds,
rebates, discounts, product tying or other programs are of a limited duration that is clearlyand conspicuously disclosed to the registrar when offered) of no less than thirty (30)
calendar days. Registry Operator shall offer registrars the option to obtain initial domainname registrations for periods of one (1) to ten (10) years at the discretion of the registrar,
but no greater than ten (10) years.
(b)With respect to renewal of domain name registrations, Registry
Operator shall provide each ICANN accredited registrar that has executed theRegistry-Registrar Agreement for the TLD advance written notice of any price increase(including as a result of the elimination of any refunds, rebates, discounts, product tying,
Qualified Marketing Programs or other programs which had the effect of reducing the pricecharged to registrars) of no less than one hundred eighty (180) calendar days.
Notwithstanding the foregoing sentence, with respect to renewal of domain nameregistrations: (i) Registry Operator need only provide thirty (30) calendar days notice ofany price increase if the resulting price is less than or equal to (A) for the period beginningon the Effective Date and ending twelve (12) months following the Effective Date, the initial
price charged for registrations in the TLD, or (B) for subsequent periods, a price for which
Registry Operator provided a notice pursuant to the first sentence of this Section 2.10(b)within the twelve (12) month period preceding the effective date of the proposed priceincrease; and (ii) Registry Operator need not provide notice of any price increase for theimposition of the Variable Registry-Level Fee set forth in Section 6.3. Registry Operator
shall offer registrars the option to obtain domain name registration renewals at the current

5price (i.e., the price in place prior to any noticed increase) for periods of one (1) to ten (10)years at the discretion of the registrar, but no greater than ten (10) years.
(c)
In addition, Registry Operator must have uniform pricing for renewalsof domain name registrations (“Renewal Pricing”). For the purposes of determining
Renewal Pricing, the price for each domain registration renewal must be identical to theprice of all other domain name registration renewals in place at the time of such renewal,
and such price must take into account universal application of any refunds, rebates,
discounts, product tying or other programs in place at the time of renewal. The foregoing
requirements of this Section 2.10(c) shall not apply for (i) purposes of determining
Renewal Pricing if the registrar has provided Registry Operator with documentation that
demonstrates that the applicable registrant expressly agreed in its registration agreementwith registrar to higher Renewal Pricing at the time of the initial registration of the domainname following clear and conspicuous disclosure of such Renewal Pricing to suchregistrant, and (ii) discounted Renewal Pricing pursuant to a Qualified Marketing Program(as defined below). The parties acknowledge that the purpose of this Section 2.10(c) is toprohibit abusive and/or discriminatory Renewal Pricing practices imposed by Registry
Operator without the written consent of the applicable registrant at the time of the initial
registration of the domain and this Section 2.10(c) will be interpreted broadly to prohibit
such practices. For purposes of this Section 2.10(c), a “Qualified Marketing Program” is amarketing program pursuant to which Registry Operator offers discounted Renewal
Pricing, provided that each of the following criteria is satisfied: (i) the program and related
discounts are offered for a period of time not to exceed one hundred eighty (180) calendar
days (with consecutive substantially similar programs aggregated for purposes ofdetermining the number of calendar days of the program), (ii) all ICANN accredited
registrars are provided the same opportunity to qualify for such discounted Renewal
Pricing; and (iii) the intent or effect of the program is not to exclude any particularclass(es) of registrations (e.g., registrations held by large corporations) or increase therenewal price of any particular class(es) of registrations. Nothing in this Section 2.10(c)shall limit Registry Operator’s obligations pursuant to Section 2.10(b).
(d)
Registry Operator shall provide public query-based DNS lookup
service for the TLD (that is, operate the Registry TLD zone servers) at its sole expense.
2.11

Contractual and Operational 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 1 of this Agreement and its covenants contained in Article 2 of this Agreement. Suchaudits shall be tailored to achieve the purpose of assessing compliance, and ICANN will (a)give reasonable advance notice of any such audit, which notice shall specify in reasonabledetail the categories of documents, data and other information requested by ICANN, and(b) use commercially reasonable efforts to conduct such audit during regular businesshours and 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
6

provide all responsive documents, data and any other information reasonably necessary todemonstrate 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 businesshours to assess compliance by Registry Operator with its representations and warranties
contained in Article 1 of this Agreement and its covenants contained in Article 2 of thisAgreement. ICANN will treat any information obtained in connection with such audits thatis appropriately marked as confidential (as required by Section 7.15) as Confidential
Information of Registry Operator in accordance with Section 7.15.
(b)
Any audit conducted pursuant to Section 2.11(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’scompliance with Section 2.14, 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 2.14, or (ii) the audit is related to adiscrepancy in the fees paid by Registry Operator hereunder in excess of 5% in a given
quarter 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 suchcase of (i) or (ii) above, such reimbursement will be paid together with the next RegistryLevel Fee payment due following the date of transmittal of the cost statement for suchaudit.
(c)
Notwithstanding Section 2.11(a), if Registry Operator is found not to
be in compliance with its representations and warranties contained in Article 1 of thisAgreement or its covenants contained in Article 2 of this Agreement in two consecutive
audits conducted pursuant to this Section 2.11, ICANN may increase the number of suchaudits 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 4.3(d) or the occurrence of any of the matters specified in Section 4.3(f).
2.12 Continued Operations Instrument. Registry Operator shall comply withthe terms and conditions relating to the Continued Operations Instrument set forth inSpecification 8 attached hereto (“Specification 8”).
2.13 Emergency Transition. Registry Operator agrees that, in the event that anyof 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>) (asthe same may be amended from time to time, the “Registry Transition Process”) until such7time as Registry Operator has demonstrated to ICANN’s reasonable satisfaction that it canresume operation of the registry for the TLD without the reoccurrence of such failure.
Following such demonstration, Registry Operator may transition back into operation of theregistry 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 resultof the designation of the Emergency Operator and (ii) by the Emergency Operator inconnection 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 theevent ICANN designates an Emergency Operator pursuant to this Section 2.13 and theRegistry Transition Process, Registry Operator shall provide ICANN or any such Emergency
Operator with all data (including the data escrowed in accordance with Section 2.3)
regarding operations of the registry for the TLD necessary to maintain operations andregistry 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 thatan Emergency Operator is designated pursuant to this Section 2.13. In addition, in theevent of such failure, ICANN shall retain and may enforce its rights under the Continued
Operations Instrument.
2.14 Registry 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 forthin Specification 9 attached hereto (“Specification 9”).
2.15 Cooperation with Economic Studies. If ICANN initiates or commissions an
economic study on the impact or functioning of new generic top-level domains on theInternet, the DNS or related matters, Registry Operator shall reasonably cooperate withsuch study, including by delivering to ICANN or its designee conducting such study all data
related to the operation of the TLD reasonably necessary for the purposes of such study
requested by ICANN or its designee, provided, that Registry Operator may withhold (a) any
internal analyses or evaluations prepared by Registry Operator with respect to such dataand (b) any data to the extent that the delivery of such data would be in violation of
applicable law. Any data delivered to ICANN or its designee pursuant to this Section 2.15
that is appropriately marked as confidential (as required by Section 7.15) shall be treatedas Confidential Information of Registry Operator in accordance with Section 7.15, provided
that, if ICANN aggregates and makes anonymous such data, ICANN or its designee may
disclose such data to any third party. Following completion of an economic study for which
Registry Operator has provided data, ICANN will destroy all data provided by Registry
Operator that has not been aggregated and made anonymous.
2.16 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.

8

2.17 Additional Public Interest Commitments. Registry Operator shall comply
with the public interest commitments set forth in Specification 11 attached hereto(“Specification 11”).
2.18 Personal Data. Registry Operator shall (i) notify each ICANN-accredited
registrar that is a party to the Registry-Registrar Agreement for the TLD of the purposes forwhich data about any identified or identifiable natural person (“Personal Data”) submitted
to Registry Operator by such registrar is collected and used under this Agreement orotherwise 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 suchcollection and use of Personal Data. Registry Operator shall take reasonable steps toprotect Personal Data collected from such registrar from loss, misuse, unauthorized
disclosure, alteration or destruction. Registry Operator shall not use or authorize the useof Personal Data in a way that is incompatible with the notice provided to registrars.
2.19 [Note: For Community-Based TLDs Only] Obligations of Registry
Operator to TLD Community. Registry Operator shall establish registration policies inconformity with the application submitted 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 purposeof the community-based TLD. Registry Operator shall operate the TLD in a manner thatallows the TLD community to discuss and participate in the development and modificationof policies and practices for the TLD. Registry Operator shall establish procedures for theenforcement of registration policies for the TLD, and resolution of disputes concerningcompliance 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 2.19. Registry Operator shall
implement and comply with the community registration policies set forth on Specification
12 attached hereto.]
ARTICLE 3.
COVENANTS OF ICANNICANN covenants and agrees with Registry Operator as follows:
3.1
Open and Transparent. Consistent with ICANN’s expressed mission andcore values, ICANN shall operate in an open and transparent manner.
3.2
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 reasonablecause.
3.3
TLD Nameservers. ICANN will use commercially reasonable efforts toensure that any changes to the TLD nameserver designations submitted to ICANN by9

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.
3.4
Root-zone Information Publication. ICANN’s publication of root-zone
contact information for the TLD will include Registry Operator and its administrative andtechnical 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.iana.org/domains/root/.
3.5
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 (a) ensure that theauthoritative root will point to the top-level domain nameservers designated by Registry
Operator for the TLD, (b) 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 (c) 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 thatany third party (including any governmental entity or internet service provider) blocks or
restricts access to the TLD in any jurisdiction.
ARTICLE 4.
TERM AND TERMINATION
4.1
Term. The term of this Agreement will be ten (10) years from the Effective
Date (as such term may be extended pursuant to Section 4.2, the “Term”).
4.2

Renewal.

(a)This Agreement will be renewed for successive periods of ten (10)years upon the expiration of the initial Term set forth in Section 4.1 and each successive
Term, unless:(i)
Following notice by ICANN to Registry Operator of afundamental and material breach of Registry Operator’s covenants set forthin Article 2 or breach of its payment obligations under Article 6 of thisAgreement, which notice shall include with specificity the details of thealleged breach, and such breach has not been cured within thirty (30)
calendar days of such notice, (A) an arbitrator or court of competentjurisdiction has finally determined that Registry Operator has been in
fundamental and material breach of such covenant(s) or in breach of its
payment obligations, and (B) Registry Operator has failed to comply withsuch determination and cure such breach within ten (10) calendar days orsuch other time period as may be determined by the arbitrator or court ofcompetent jurisdiction; or
10

(ii)
During the then current Term, Registry Operator shall havebeen found by an arbitrator (pursuant to Section 5.2 of this Agreement) or a
court of competent jurisdiction on at least three (3) separate occasions tohave been in (A) fundamental and material breach (whether or not cured) of
Registry Operator’s covenants set forth in Article 2 or (B) breach of its
payment obligations under Article 6 of this Agreement.
(b)Upon the occurrence of the events set forth in Section 4.2(a) (i) or (ii),the Agreement shall terminate at the expiration of the then-current Term.
4.3

Termination by ICANN.

(a)ICANN may, upon notice to Registry Operator, terminate thisAgreement if: (i) Registry Operator fails to cure (A) any fundamental and material breachof Registry Operator’s representations and warranties set forth in Article 1 or covenants
set forth in Article 2, or (B) any breach of Registry Operator’s payment obligations set forthin Article 6 of this Agreement, each within thirty (30) calendar days after ICANN gives
Registry Operator notice of such breach, which notice will include with specificity thedetails of the alleged breach, (ii) an arbitrator or court of competent jurisdiction has finallydetermined that Registry Operator is in fundamental and material breach of suchcovenant(s) or in breach of its payment obligations, and (iii) Registry Operator fails tocomply with such determination and cure such breach within ten (10) calendar days orsuch other time period as may be determined by the arbitrator or court of competentjurisdiction.
(b)
ICANN may, upon notice to Registry Operator, terminate thisAgreement if Registry Operator fails to complete all testing and procedures (identified by
ICANN in writing to Registry Operator prior to the date hereof) for delegation of the TLD
into the root zone within twelve (12) months of the Effective Date. Registry Operator may
request an extension for up to additional twelve (12) months for delegation if it candemonstrate, to ICANN’s reasonable satisfaction, that Registry Operator is working
diligently and in good faith toward successfully completing the steps necessary fordelegation of the TLD. Any fees paid by Registry Operator to ICANN prior to suchtermination date shall be retained by ICANN in full.
(c)
ICANN may, upon notice to Registry Operator, terminate thisAgreement if (i) Registry Operator fails to cure a material breach of Registry Operator’s
obligations set forth in Section 2.12 of this Agreement within thirty (30) calendar days ofdelivery of notice of such breach by ICANN, or if the Continued Operations Instrument is
not in effect for greater than sixty (60) consecutive calendar days at any time following theEffective Date, (ii) an arbitrator or court of competent jurisdiction has finally determinedthat Registry Operator is in material breach of such covenant, and (iii) Registry Operator
fails to cure such breach within ten (10) calendar days or such other time period as may be
determined by the arbitrator or court of competent jurisdiction.

11

(d)
ICANN may, upon notice to Registry Operator, terminate thisAgreement if (i) Registry Operator makes an assignment for the benefit of creditors orsimilar act, (ii) attachment, garnishment or similar proceedings are commenced against
Registry Operator, which proceedings are a material threat to Registry Operator’s ability tooperate 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 placeof 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 tooperate the registry for the TLD, (v) proceedings are instituted by or against Registry
Operator under any bankruptcy, insolvency, reorganization or other laws relating to therelief 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 suchproceedings 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.
(e)
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 2, Section 3 or any other applicable Section of Specification 11, subject toRegistry Operator’s right to challenge such termination as set forth in the applicable
procedure described therein.
(f)
ICANN may, upon notice to Registry Operator, terminate thisAgreement if (i) Registry Operator knowingly employs any officer who is convicted of amisdemeanor related to financial activities or of any felony, or is judged by a court ofcompetent 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 ofRegistry Operator’s board of directors or similar governing body is convicted of amisdemeanor related to financial activities or of any felony, or is judged by a court ofcompetent 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 ofRegistry Operator’s knowledge of the foregoing.
(g)
ICANN may, upon thirty (30) calendar days’ notice to Registry
Operator, terminate this Agreement as specified in Section 7.5.
(h)[Applicable to intergovernmental organizations or governmental
entities only.] ICANN may terminate this Agreement pursuant to Section 7.16.
12

4.4

Termination by Registry Operator.

(a)Registry Operator may terminate this Agreement upon notice to
ICANN if (i) ICANN fails to cure any fundamental and material breach of ICANN’s covenants
set forth in Article 3, within thirty (30) calendar days after Registry Operator gives ICANN
notice of such breach, which notice will include with specificity the details of the alleged
breach, (ii) an arbitrator or court of competent jurisdiction has finally determined that
ICANN is in fundamental and material breach of such covenants, and (iii) ICANN fails tocomply with such determination and cure such breach within ten (10) calendar days orsuch other time period as may be determined by the arbitrator or court of competentjurisdiction.
(b)Registry Operator may terminate this Agreement for any reason upon
one hundred eighty (180) calendar day advance notice to ICANN.
4.5
Transition of Registry upon Termination of Agreement. Upon expirationof the Term pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement
pursuant to Section 4.3 or Section 4.4, Registry Operator shall provide ICANN or any
successor registry operator that may be designated by ICANN for the TLD in accordancewith this Section 4.5 with all data (including the data escrowed in accordance with Section2.3) regarding operations of the registry for the TLD necessary to maintain operations andregistry 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 andin conformance with the Registry Transition Process; provided, however, that (i) ICANN
will take into consideration any intellectual property rights of Registry Operator (ascommunicated 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 suchapplication 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 4.5. In addition, ICANN or its designee shall retain and may enforce its rights
under the Continued Operations Instrument for the maintenance and operation of the TLD,
regardless of the reason for termination or expiration of this Agreement.

13

[Alternative Section 4.5 Transition of Registry upon Termination of Agreement
text for intergovernmental organizations or governmental entities or other special
circumstances:“Transition of Registry 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 Section 4.3 or Section 4.4, in connection with ICANN’s designation of a successor registry
operator for the TLD, Registry Operator and ICANN agree to consult each other and work
cooperatively to facilitate and implement the transition of the TLD in accordance with thisSection 4.5. 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. In the event ICANN determines
to transition operation of the TLD to a successor registry operator, upon Registry
Operator’s consent (which shall not be unreasonably withheld, conditioned or delayed),
Registry Operator shall provide ICANN or such successor registry operator for the TLD
with any data regarding operations of the TLD necessary to maintain operations andregistry functions that may be reasonably requested by ICANN or such successor registry
operator in addition to data escrowed in accordance with Section 2.3 hereof. In the eventthat Registry Operator does not consent to provide such data, any registry data related to
the TLD shall be returned to Registry Operator, unless otherwise agreed upon by theparties. 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 atransition of the TLD pursuant to this Section 4.5. In addition, ICANN or its designee shallretain and may enforce its rights under the Continued Operations Instrument, regardless of
the reason for termination or expiration of this Agreement.”]
4.6
Effect of Termination. Upon any expiration of the Term or termination ofthis Agreement, the obligations and rights of the parties hereto shall cease, provided thatsuch 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 Article 6. In
addition, Article 5, Article 7, Section 2.12, Section 4.5, and this Section 4.6 shall survive theexpiration or termination of this Agreement. For the avoidance of doubt, the rights ofRegistry Operator to operate the registry for the TLD shall immediately cease upon any
expiration of the Term or termination of this Agreement.
ARTICLE 5.
DISPUTE RESOLUTION
5.1
Mediation. In the event of any dispute arising under or in connection withthis Agreement, before either party may initiate arbitration pursuant to Section 5.2 below,
ICANN and Registry Operator must attempt to resolve the dispute through mediation inaccordance with the following terms and conditions:

14

(a)
A party shall submit a dispute to mediation by written notice to theother 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, the parties will promptly select a mutuallyacceptable mediation provider entity, which entity shall, as soon as practicable following
such entity’s selection, designate a mediator, who is a licensed attorney with generalknowledge of contract law, has no ongoing business relationship with either party and, tothe extent necessary to mediate the particular dispute, general knowledge of the domainname 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 thisSection 5.1(a).
(b)
The mediator shall conduct the mediation in accordance with therules 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 treatedas 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.2. The mediator may not testify for either party in any later
proceeding relating to the dispute.
(c)Each party shall bear its own costs in the mediation. The parties shallshare 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 asconfidential (as required by Section 7.15) as Confidential Information of such other party inaccordance with Section 7.15.
(d)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.2 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), the mediation shall automatically terminate (unless extended byagreement of the parties) and the dispute can then proceed to arbitration pursuant to
Section 5.2 below.
5.2
Arbitration. Disputes arising under or in connection with this Agreementthat are not resolved pursuant to Section 5.1, including requests for specific performance,
will be resolved through binding arbitration conducted pursuant to the rules of theInternational 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 isseeking punitive or exemplary damages, or operational sanctions, (ii) the parties agree in
writing to a greater number of arbitrators, or (iii) the dispute arises under Section 7.6 or
15

7.7. In the case of clauses (i), (ii) or (iii) in the preceding sentence, the arbitration will be infront 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 theparties fail to nominate a sole arbitrator or, in the case of an arbitration in front of threearbitrators, 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 theother 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 nominatedarbitrator 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 forthe 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 thearbitrators determine that Registry Operator has been repeatedly and willfully infundamental and material breach of its obligations set forth in Article 2, Article 6 or Section
5.4 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 required by Section 7.15) as Confidential Information of suchother party in accordance with Section 7.15. 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 toenforce a judgment of such a court in any court of competent jurisdiction.
[Alternative Section 5.2 Arbitration text for intergovernmental organizations or
governmental entities or other special circumstances:“Arbitration. Disputes arising under or in connection with this Agreement that are
not resolved pursuant to Section 5.1, 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 Geneva, Switzerland, unless
another location is mutually agreed upon by Registry Operator and ICANN. Any arbitration
will be in front of a single arbitrator, unless (i) ICANN is seeking punitive or exemplary
damages, or operational sanctions, (ii) the parties agree in writing to a greater number ofarbitrators, or (iii) the dispute arises under Section 7.6 or 7.7. In the case of clauses (i), (ii)or (iii) in the preceding sentence, the arbitration will be in front of three arbitrators with16

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 arbitrationin 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 asole 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 whena 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, thearbitrator(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 areplacement arbitrator for confirmation by the ICC. In order to expedite the arbitrationand limit its cost, the arbitrator(s) shall establish page limits for the parties’ filings inconjunction with the arbitration, and should the arbitrator(s) determine that a hearing isnecessary, 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 operationalsanctions, the hearing may be extended for one (1) additional calendar day if agreed uponby 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 determinethat Registry Operator has been repeatedly and willfully in fundamental and material
breach of its obligations set forth in Article 2, Article 6 or Section 5.4 of this Agreement,
ICANN may request the arbitrators award punitive or exemplary damages, or operationalsanctions (including without limitation an order temporarily restricting Registry
Operator’s right to sell new registrations). Each party shall treat information received fromthe other party pursuant to the arbitration that is appropriately marked as confidential (asrequired by Section 7.15) as Confidential Information of such other party in accordancewith Section 7.15. In any litigation involving ICANN concerning this Agreement,
jurisdiction and exclusive venue for such litigation will be in a court located in Geneva,
Switzerland, unless another location is mutually agreed upon by Registry Operator and
ICANN; however, the parties will also have the right to enforce a judgment of such a courtin any court of competent jurisdiction.”]
5.3
Limitation of Liability. ICANN’s aggregate monetary liability for violationsof this Agreement will not exceed an amount equal to the Registry-Level Fees paid by
Registry Operator to ICANN within the preceding twelve-month period pursuant to thisAgreement (excluding the Variable Registry-Level Fee set forth in Section 6.3, if any).
Registry Operator’s aggregate monetary liability to ICANN for breaches of this Agreement
will be limited to an amount equal to the fees paid to ICANN during the preceding
twelve-month period (excluding the Variable Registry-Level Fee set forth in Section 6.3, ifany), and punitive and exemplary damages, if any, awarded in accordance with Section 5.2,
except with respect to Registry Operator’s indemnification obligations pursuant to Section
7.1 and Section 7.2. In no event shall either party be liable for special, punitive, exemplaryor consequential damages arising out of or in connection with this Agreement or the
performance or nonperformance of obligations undertaken in this Agreement, except asprovided in Section 5.2. Except as otherwise provided in this Agreement, neither party
17

makes any warranty, express or implied, with respect to the services rendered by itself, its
servants or agents, or the results obtained from their work, including, without limitation,
any implied warranty of merchantability, non-infringement or fitness for a particularpurpose.
5.4
Specific Performance. Registry Operator and ICANN agree that irreparable
damage could occur if any of the provisions of this Agreement was not performed inaccordance with its specific terms. Accordingly, the parties agree that they each shall beentitled to seek from the arbitrator or court of competent jurisdiction specific performanceof the terms of this Agreement (in addition to any other remedy to which each party isentitled).
ARTICLE 6.
FEES
6.1

Registry-Level Fees.

(a)
Registry Operator shall pay ICANN a registry-level fee equal to (i) the
registry fixed fee of US$6,250 per calendar quarter and (ii) the registry-level transactionfee (collectively, the “Registry-Level Fees”). The registry-level transaction fee will be equal
to the number of annual increments of an initial or renewal domain name registration (atone or more levels, and including renewals associated with transfers from one
ICANN-accredited registrar to another, each a “Transaction”), during the applicable
calendar quarter multiplied by US$0.25; provided, however that the registry-leveltransaction fee shall not apply until and unless more than 50,000 Transactions haveoccurred in the TLD during any calendar quarter or any consecutive four calendar quarter
period in the aggregate (the “Transaction Threshold”) and shall apply to each Transactionthat occurred during each quarter in which the Transaction Threshold has been met, butshall not apply to each quarter in which the Transaction Threshold has not been met.
Registry Operator’s obligation to pay the quarterly registry-level fixed fee will begin on thedate on which the TLD is delegated in the DNS to Registry Operator. The first quarterly
payment of the registry-level fixed fee will be prorated based on the number of calendar
days between the delegation date and the end of the calendar quarter in which thedelegation date falls.
(b)
Subject to Section 6.1(a), Registry Operator shall pay theRegistry-Level Fees on a quarterly basis to an account designated by ICANN within thirty(30) calendar days following the date of the invoice provided by ICANN.
6.2
Cost Recovery for RSTEP. Requests by Registry Operator for the approvalof Additional Services pursuant to Section 2.1 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,
18

unless ICANN determines, in its sole and absolute discretion, to pay all or any portion of theinvoiced cost of such RSTEP review.
6.3

Variable Registry-Level Fee.

(a)
If the ICANN accredited registrars (accounting, in the aggregate, forpayment 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 afiscal 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 andinvoiced 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 withintwenty (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 andcollect the Variable Registry-Level Fees from the registrars that are party to a
Registry-Registrar Agreement with Registry Operator (which agreement may specificallyprovide for the reimbursement of Variable Registry-Level Fees paid by Registry Operator
pursuant to this Section 6.3); 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 asprovided in this Section 6.3 irrespective of Registry Operator’s ability to seek and obtainreimbursement of such fee from registrars. In the event ICANN later collects variableaccreditation 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 agreementswith ICANN, the variable accreditation fees established by the ICANN Board of Directors fora 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.
(b)
The amount of the Variable Registry-Level Fee will be specified foreach registrar, and may include both a per-registrar component and a transactional
component. 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. 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.

19

6.4
Pass Through Fees. Registry Operator shall pay to ICANN (i) a one-time fee
equal to US$5,000 for access to and use of the Trademark Clearinghouse as described inSpecification 7 (the “RPM Access Fee”) and (ii) US$0.25 per Sunrise Registration and Claims
Registration (as such terms are used in Trademark Clearinghouse RPMs incorporated
herein pursuant to Specification 7) (the “RPM Registration Fee”). The RPM Access Fee will
be invoiced as of the Effective Date of this Agreement, and Registry Operator shall pay suchfee to an account specified by ICANN within thirty (30) calendar days following the date of
the invoice. ICANN will invoice Registry Operator quarterly for the RPM Registration Fee,
which shall be due in accordance with the invoicing and payment procedure specified in
Section 6.1.
6.5
Adjustments to Fees. Notwithstanding any of the fee limitations set forth in
this Article 6, commencing upon the expiration of the first year of this Agreement, and upon
the expiration of each year thereafter during the Term, the then-current fees set forth in
Section 6.1 and Section 6.3 may be adjusted, at ICANN’s discretion, by a percentage equal tothe percentage change, if any, in (i) the Consumer Price Index for All Urban Consumers, U.S.
City Average (1982-1984 = 100) published by the United States Department of Labor,
Bureau of Labor Statistics, or any successor index (the “CPI”) for the month which is one(1) month prior to the commencement of the applicable year, over (ii) the CPI published forthe month which is one (1) month prior to the commencement of the immediately prioryear. In the event of any such increase, ICANN shall provide notice to Registry Operator
specifying the amount of such adjustment. Any fee adjustment under this Section 6.5 shallbe effective as of the first day of the first calendar quarter following at least thirty (30) days
after ICANN’s delivery to Registry Operator of such fee adjustment notice.
6.6
Additional Fee on Late Payments. For any payments thirty (30) calendar
days or more overdue under this Agreement, Registry Operator shall pay an additional fee
on late payments at the rate of 1.5% per month or, if less, the maximum rate permitted byapplicable law.
6.7
Fee Reduction Waiver. In ICANN’s sole discretion, ICANN may reduce theamount of registry fees payable hereunder by Registry Operator for any period of time(“Fee Reduction Waiver”). Any such Fee Reduction Waiver may, as determined by ICANN
in its sole discretion, be (a) limited in duration and (b) conditioned upon Registry
Operator’s acceptance of the terms and conditions set forth in such waiver. A Fee
Reduction Waiver shall not be effective unless executed in writing by ICANN ascontemplated by Section 7.6(i). ICANN will provide notice of any Fee Reduction Waiver toRegistry Operator in accordance with Section 7.9.
ARTICLE 7.
MISCELLANEOUS
7.1

Indemnification of ICANN.

20

(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 feesand expenses, arising out of or relating to intellectual property ownership rights withrespect to the TLD, the delegation of the TLD to Registry Operator, Registry Operator’soperation of the registry for the TLD or Registry Operator’s provision of Registry 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 theactions or omissions of ICANN, its subcontractors, panelists or evaluators specificallyrelated to and occurring during the registry TLD application process (other than actions oromissions 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 withany litigation or arbitration between or among the parties, which shall be governed by
Article 5 or otherwise awarded by a court of competent jurisdiction or arbitrator.
[Alternative Section 7.1(a) text for intergovernmental organizations or
governmental entities:“Registry Operator shall use its best efforts to cooperate with ICANN in order toensure that ICANN does not incur any costs associated with 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 Registry Services, provided that Registry Operator shall not be
obligated to provide such cooperation to the extent the claim, damage, liability, cost or
expense arose due to a breach by ICANN of any of its obligations contained in thisAgreement or any willful misconduct by ICANN. This Section shall not be deemed torequire Registry Operator to reimburse or otherwise indemnify ICANN for costs associatedwith 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 5 or otherwise awarded by a court ofcompetent jurisdiction or arbitrator.”](b)
For any claims by ICANN for indemnification whereby multiple
registry operators (including Registry Operator) have engaged in the same actions oromissions 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 6 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 are21

engaging in the same acts or omissions giving rise to such claim. For the purposes of
reducing Registry Operator’s liability under Section 7.1(a) pursuant to this Section 7.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 nothave the same or similar indemnification obligations to ICANN as set forth in Section 7.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. [Note: This Section
7.1(b) is inapplicable to intergovernmental organizations or governmental entities.]
7.2
Indemnification Procedures. If any third-party claim is commenced that isindemnified under Section 7.1 above, ICANN shall provide notice thereof to Registry
Operator 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 andinvestigation of such claim and to employ and engage attorneys reasonably acceptable to
ICANN to handle and defend the same, at Registry Operator’s sole cost and expense,
provided that in all events ICANN will be entitled to control at its sole cost and expense thelitigation of issues concerning the validity or interpretation of ICANN’s policies, Bylaws or
conduct. ICANN shall cooperate, at Registry Operator’s cost and expense, in all reasonable
respects with Registry Operator and its attorneys in the investigation, trial, and defense ofsuch claim and any appeal arising therefrom, and may, at its own cost and expense,
participate, through its attorneys or otherwise, in such investigation, trial and defense ofsuch claim and any appeal arising therefrom. No settlement of a claim that involves aremedy affecting ICANN other than the payment of money in an amount that is fully
indemnified by Registry Operator will be entered into without the consent of ICANN. If
Registry Operator does not assume full control over the defense of a claim subject to suchdefense in accordance with this Section 7.2, ICANN will have the right to defend the claim insuch manner as it may deem appropriate, at the cost and expense of Registry Operator andRegistry Operator shall cooperate in such defense. [Note: This Section 7.2 is inapplicable
to intergovernmental organizations or governmental entities.]
7.3
Defined Terms. For purposes of this Agreement, unless such definitions areamended 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 the 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 bysystems 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 andpublished by a well-established and recognized Internet standards body, such as the22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 thatadversely affects the throughput, response time, consistency or coherence of responses toInternet servers or end systems operating in accordance with applicable relevant
standards that are authoritative and published by a well-established and recognizedInternet standards body, such as the relevant Standards-Track or Best Current Practice
RFCs, and relying on Registry Operator’s delegated information or provisioning of services.
7.4
No Offset. All payments due under this Agreement will be made in a timely
manner throughout the Term and notwithstanding the pendency of any dispute (monetaryor otherwise) between Registry Operator and ICANN.
7.5
Change of Control; Assignment and Subcontracting. Except as set forth in
this Section 7.5, neither party may assign any of its rights and obligations under thisAgreement without the prior written approval of the other party, which approval will not
be unreasonably withheld. For purposes of this Section 7.5, a direct or indirect change ofcontrol 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, andany agreement to assign or subcontract any portion of the operations of the TLD (whether
or not a Material Subcontracting Arrangement) must mandate compliance with allcovenants, 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 noticeto ICANN prior to the consummation of any transaction anticipated to result in a direct orindirect change of control of Registry Operator.
(b)Within thirty (30) calendar days of either such notification pursuant
to Section 7.5(a), ICANN may request additional information from Registry Operator
establishing (i) compliance with this Agreement and (ii) that the party acquiring suchcontrol or entering into such assignment or Material Subcontracting Arrangement (in any
case, the “Contracting Party”) and the ultimate parent entity of the Contracting Party meetsthe 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 tobackground checks on any proposed Contracting Party (and such Contracting Party’s
Affiliates).

23

(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 noticeof 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 tohave 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 ofcontrol shall not be voidable by ICANN; provided, however, that, if ICANN reasonably
determines to withhold its consent to such transaction, ICANN may terminate thisAgreement pursuant to Section 4.3(g), (ii) ICANN may assign this Agreement without theconsent 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 an Affiliated Assignee,as that term is defined herein below, upon such Affiliated Assignee’s express written
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 ofcontrol 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 andconditions of such registry agreement in all material respects), unless ICANN provides toRegistry 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 7.5. Notwithstanding
Section 7.5(a), in the event an assignment is made pursuant to clauses (ii) or (iii) of thisSection 7.5(f), the assigning party will provide the other party with prompt notice following
any such assignment. For the purposes of this Section 7.5(f), (A) “Affiliated Assignee”
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 (B) “control” (including the terms “controlled by” and “under common control with”)
shall have the same meaning specified in Section 2.9(c) of this Agreement.
7.6

Amendments and Waivers.

(a)
If the ICANN Board of Directors determines that an amendment to thisAgreement (including to the Specifications referred to herein) and all other registryagreements between ICANN and the Applicable Registry Operators (the “Applicable
Registry Agreements”) is desirable (each, a “Special Amendment”), ICANN may adopt a
Special Amendment pursuant to the requirements of and process set forth in this Section
7.6; provided that a Special Amendment may not be a Restricted Amendment.

24

(b)
Prior to submitting a Special Amendment for Registry Operator
Approval, ICANN shall first consult in good faith with the Working Group regarding theform and substance of such Special Amendment. The duration of such consultation shall bereasonably determined by ICANN based on the substance of the Special Amendment.
Following such consultation, ICANN may propose the adoption of a Special Amendment by
publicly posting such amendment on its website for no less than thirty (30) calendar days
(the “Posting Period”) and providing notice of such proposed amendment to the Applicable
Registry Operators in accordance with Section 7.9. ICANN will consider the publiccomments submitted on a Special Amendment during the Posting Period (includingcomments submitted by the Applicable Registry Operators).
(c)
If, within one hundred eighty (180) calendar days following the
expiration of the Posting Period (the “Approval Period”), the ICANN Board of Directors
approves a Special Amendment (which may be in a form different than submitted for publiccomment, but must address the subject matter of the Special Amendment posted for publiccomment, as modified to reflect and/or address input from the Working Group and publiccomments), ICANN shall provide notice of, and submit, such Special Amendment for
approval or disapproval by the Applicable Registry Operators. If, during the sixty (60)calendar day period following the date ICANN provides such notice to the Applicable
Registry Operators, such Special Amendment receives Registry Operator Approval, suchSpecial Amendment shall be deemed approved (an “Approved Amendment”) by the
Applicable Registry Operators, and shall be effective and deemed an amendment to thisAgreement on the date that is sixty (60) calendar days following the date ICANN provided
notice of the approval of such Approved Amendment to Registry Operator (the“Amendment Effective Date”). In the event that a Special Amendment does not receive
Registry Operator Approval, the Special Amendment shall be deemed not approved by the
Applicable Registry Operators (a “Rejected Amendment”). A Rejected Amendment will
have no effect on the terms and conditions of this Agreement, except as set forth below.
(d)
If the ICANN Board of Directors reasonably determines that a Rejected
Amendment falls within the subject matter categories set forth in Section 1.2 ofSpecification 1, the ICANN Board of Directors may adopt a resolution (the date such
resolution is adopted is referred to herein as the “Resolution Adoption Date”) requesting an
Issue Report (as such term is defined in ICANN’s Bylaws) by the Generic Names Supporting
Organization (the “GNSO”) regarding the substance of such Rejected Amendment. The
policy development process undertaken by the GNSO pursuant to such requested Issue
Report is referred to herein as a “PDP.” If such PDP results in a Final Report supported by a
GNSO Supermajority (as defined in ICANN’s Bylaws) that either (i) recommends adoptionof the Rejected Amendment as Consensus Policy or (ii) recommends against adoption of
the Rejected Amendment as Consensus Policy, and, in the case of (i) above, the Board
adopts such Consensus Policy, Registry Operator shall comply with its obligations pursuant
to Section 2.2 of this Agreement. In either case, ICANN will abandon the Rejected
Amendment and it will have no effect on the terms and conditions of this Agreement.
Notwithstanding the foregoing provisions of this Section 7.6(d), the ICANN Board of
Directors shall not be required to initiate a PDP with respect to a Rejected Amendment if, at
any time in the twelve (12) month period preceding the submission of such Rejected25

Amendment for Registry Operator Approval pursuant to Section 7.6(c), the subject matterof such Rejected Amendment was the subject of a concluded or otherwise abandoned or
terminated PDP that did not result in a GNSO Supermajority recommendation.
(e)
If (a) a Rejected Amendment does not fall within the subject matter
categories set forth in Section 1.2 of Specification 1, (b) the subject matter of a Rejected
Amendment was, at any time in the twelve (12) month period preceding the submission ofsuch Rejected Amendment for Registry Operator Approval pursuant to Section 7.6(c), thesubject of a concluded or otherwise abandoned or terminated PDP that did not result in a
GNSO Supermajority recommendation, or (c) a PDP does not result in a Final Report
supported by a GNSO Supermajority that either (A) recommends adoption of the Rejected
Amendment as Consensus Policy or (B) recommends against adoption of the Rejected
Amendment as Consensus Policy (or such PDP has otherwise been abandoned or
terminated for any reason), then, in any such case, such Rejected Amendment may still be
adopted and become effective in the manner described below. In order for the Rejected
Amendment to be adopted, the following requirements must be satisfied:(i)the subject matter of the Rejected Amendment must be within
the scope of ICANN’s mission and consistent with a balanced application of
its core values (as described in ICANN’s Bylaws);(ii)
the Rejected Amendment must be justified by a Substantial andCompelling Reason in the Public Interest, must be likely to promote suchinterest, taking into account competing public and private interests that arelikely to be affected by the Rejected Amendment, and must be narrowly
tailored and no broader than reasonably necessary to address such
Substantial and Compelling Reason in the Public Interest;(iii)
to the extent the Rejected Amendment prohibits or requires
conduct or activities, imposes material costs on the Applicable Registry
Operators, and/or materially reduces public access to domain name services,
the Rejected Amendment must be the least restrictive means reasonably
available to address the Substantial and Compelling Reason in the Public
Interest;(iv)
the ICANN Board of Directors must submit the Rejected
Amendment, along with a written explanation of the reasoning related to its
determination that the Rejected Amendment meets the requirements set out
in subclauses (i) through (iii) above, for public comment for a period of noless than thirty (30) calendar days; and(v)
following such public comment period, the ICANN Board of
Directors must (a) engage in consultation (or direct ICANN management toengage in consultation) with the Working Group, subject matter experts,
members of the GNSO, relevant advisory committees and other interested
stakeholders with respect to such Rejected Amendment for a period of no26

less than sixty (60) calendar days; and (b) following such consultation,
reapprove the Rejected Amendment (which may be in a form different thansubmitted for Registry Operator Approval, but must address the subject
matter of the Rejected Amendment, as modified to reflect and/or address
input from the Working Group and public comments) by the affirmative voteof at least two-thirds of the members of the ICANN Board of Directors eligible
to vote on such matter, taking into account any ICANN policy affecting such
eligibility, including ICANN’s Conflict of Interest Policy (a “Board
Amendment”).
Such Board Amendment shall, subject to Section 7.6(f), be deemed an Approved
Amendment, and shall be effective and deemed an amendment to this Agreement on thedate that is sixty (60) calendar days following the date ICANN provided notice of theapproval of such Board Amendment to Registry Operator (which effective date shall bedeemed the Amendment Effective Date hereunder). Notwithstanding the foregoing, aBoard Amendment may not amend the registry fees charged by ICANN hereunder, oramend this Section 7.6.
(f)
Notwithstanding the provisions of Section 7.6(e), a Board Amendment
shall not be deemed an Approved Amendment if, during the thirty (30) calendar day period
following the approval by the ICANN Board of Directors of the Board Amendment, theWorking Group, on the behalf of the Applicable Registry Operators, submits to the ICANN
Board of Directors an alternative to the Board Amendment (an “Alternative Amendment”)
that meets the following requirements:(i)
sets forth the precise text proposed by the Working Group toamend this Agreement in lieu of the Board Amendment;(ii)
addresses the Substantial and Compelling Reason in the Public
Interest identified by the ICANN Board of Directors as the justification for the
Board Amendment; and(iii)
compared to the Board Amendment is: (a) more narrowly
tailored to address such Substantial and Compelling Reason in the Public
Interest, and (b) to the extent the Alternative Amendment prohibits or
requires conduct or activities, imposes material costs on Affected Registry
Operators, or materially reduces access to domain name services, is a lessrestrictive means to address the Substantial and Compelling Reason in the
Public Interest.
Any proposed amendment that does not meet the requirements of subclauses (i) through(iii) in the immediately preceding sentence shall not be considered an Alternative
Amendment hereunder and therefore shall not supersede or delay the effectiveness of theBoard Amendment. If, following the submission of the Alternative Amendment to the
ICANN Board of Directors, the Alternative Amendment receives Registry Operator
Approval, the Alternative Amendment shall supersede the Board Amendment and shall be27deemed an Approved Amendment hereunder (and shall be effective and deemed anamendment to this Agreement on the date that is sixty (60) calendar days following thedate ICANN provided notice of the approval of such Alternative Amendment to Registry
Operator, which effective date shall deemed the Amendment Effective Date hereunder),unless, within a period of sixty (60) calendar days following the date that the Working
Group notifies the ICANN Board of Directors of Registry Operator Approval of such
Alternative Amendment (during which time ICANN shall engage with the Working Group
with respect to the Alternative Amendment), the ICANN Board of Directors by theaffirmative vote of at least two-thirds of the members of the ICANN Board of Directors
eligible to vote on such matter, taking into account any ICANN policy affecting such
eligibility, including ICANN’s Conflict of Interest Policy, rejects the Alternative Amendment.
If (A) the Alternative Amendment does not receive Registry Operator Approval within
thirty (30) calendar days of submission of such Alternative Amendment to the Applicable
Registry Operators (and the Working Group shall notify ICANN of the date of such
submission), or (B) the ICANN Board of Directors rejects the Alternative Amendment bysuch two-thirds vote, the Board Amendment (and not the Alternative Amendment) shall beeffective and deemed an amendment to this Agreement on the date that is sixty (60)calendar days following the date ICANN provided notice to Registry Operator (which
effective date shall deemed the Amendment Effective Date hereunder). If the ICANN Boardof Directors rejects an Alternative Amendment, the board shall publish a written rationale
setting forth its analysis of the criteria set forth in Sections 7.6(f)(i) through 7.6(f)(iii). The
ability of the ICANN Board of Directors to reject an Alternative Amendment hereunder does
not relieve the Board of the obligation to ensure that any Board Amendment meets thecriteria set forth in Section 7.6(e)(i) through 7.6(e)(v).
(g)
In the event that Registry Operator believes an Approved Amendment
does not meet the substantive requirements set out in this Section 7.6 or has been adopted
in contravention of any of the procedural provisions of this Section 7.6, Registry Operator
may challenge the adoption of such Special Amendment pursuant to the dispute resolution
provisions set forth in Article 5, except that such arbitration shall be conducted by athree-person arbitration panel. Any such challenge must be brought within sixty (60)calendar days following the date ICANN provided notice to Registry Operator of theApproved Amendment, and ICANN may consolidate all challenges brought by registry
operators (including Registry Operator) into a single proceeding. The Approved
Amendment will be deemed not to have amended this Agreement during the pendency ofthe dispute resolution process.
(h)Registry Operator may apply in writing to ICANN for an exemption
from the Approved Amendment (each such request submitted by Registry Operator
hereunder, an “Exemption Request”) during the thirty (30) calendar day period following
the date ICANN provided notice to Registry Operator of such Approved Amendment. Each
Exemption Request will set forth the basis for such request and provide detailed support
for an exemption from the Approved Amendment. An Exemption Request may also include
a detailed description and support for any alternatives to, or a variation of, the Approved
Amendment proposed by such Registry Operator. An Exemption Request may only be
granted upon a clear and convincing showing by Registry Operator that compliance with28

the Approved Amendment conflicts with applicable laws or would have a material adverse
effect on the long-term financial condition or results of operations of Registry Operator. No
Exemption Request will be granted if ICANN determines, in its reasonable discretion, that
granting such Exemption Request would be materially harmful to registrants or result in
the denial of a direct benefit to registrants. Within ninety (90) calendar days of ICANN’s
receipt of an Exemption Request, ICANN shall either approve (which approval may beconditioned or consist of alternatives to or a variation of the Approved Amendment) or
deny the Exemption Request in writing, during which time the Approved Amendment will
not amend this Agreement. If the Exemption Request is approved by ICANN, the Approved
Amendment will not amend this Agreement; provided, that any conditions, alternatives orvariations of the Approved Amendment required by ICANN shall be effective and, to theextent applicable, will amend this Agreement as of the Amendment Effective Date. If such
Exemption Request is denied by ICANN, the Approved Amendment will amend thisAgreement as of the Amendment Effective Date (or, if such date has passed, such Approved
Amendment shall be deemed effective immediately on the date of such denial), provided
that Registry Operator may, within thirty (30) calendar days following receipt of ICANN’s
determination, appeal ICANN’s decision to deny the Exemption Request pursuant to thedispute resolution procedures set forth in Article 5. The Approved Amendment will bedeemed not to have amended this Agreement during the pendency of the dispute
resolution process. For avoidance of doubt, only Exemption Requests submitted byRegistry Operator that are approved by ICANN pursuant to this Section 7.6(j), agreed to by
ICANN following mediation pursuant to Section 5.1 or through an arbitration decision
pursuant to Section 5.2 shall exempt Registry Operator from any Approved Amendment,
and no Exemption Request granted to any other Applicable Registry Operator (whether by
ICANN or through arbitration) shall have any effect under this Agreement or exempt
Registry Operator from any Approved Amendment.
(i)
Except as set forth in this Section 7.6, Section 7.7 and as otherwise set
forth in this Agreement and the Specifications hereto, no amendment, supplement or
modification of this Agreement or any provision hereof shall be binding unless executed inwriting by both parties, and nothing in this Section 7.6 or Section 7.7 shall restrict ICANN
and Registry Operator from entering into bilateral amendments and modifications to thisAgreement negotiated solely between the two parties. No waiver of any provision of thisAgreement 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 waiverof any other provision hereof, nor shall any such waiver constitute a continuing waiver
unless otherwise expressly provided. For the avoidance of doubt, nothing in this Sections
7.6 or 7.7 shall be deemed to limit Registry Operator’s obligation to comply with Section
2.2.
(j)For purposes of this Section 7.6, the following terms shall have thefollowing meanings:

29

(i)
“Applicable Registry Operators” means, collectively, theregistry operators of top-level domains party to a registry agreement that
contains a provision similar to this Section 7.6, including Registry Operator.
(ii)“Registry Operator Approval” means the receipt of each of thefollowing: (A) the affirmative approval of the Applicable Registry Operators
whose payments to ICANN accounted for two-thirds of the total amount offees (converted to U.S. dollars, if applicable, at the prevailing exchange rate
published the prior day in the U.S. Edition of the Wall Street Journal for thedate such calculation is made by ICANN) paid to ICANN by all the Applicable
Registry Operators during the immediately previous calendar year pursuant
to the Applicable Registry Agreements, and (B) the affirmative approval of amajority of the Applicable Registry Operators at the time such approval is
obtained. For the avoidance of doubt, with respect to clause (B), eachApplicable Registry Operator shall have one vote for each top-level domain
operated by such Registry Operator pursuant to an Applicable Registry
Agreement.
(iii)“Restricted Amendment” means the following: (A) an
amendment of Specification 1, (B) except to the extent addressed in Section
2.10 hereof, an amendment that specifies the price charged by Registry
Operator to registrars for domain name registrations, (C) an amendment to
the definition of Registry Services as set forth in the first paragraph of
Section 2.1 of Specification 6, or (D) an amendment to the length of the Term.
(iv)“Substantial and Compelling Reason in the Public Interest”
means a reason that is justified by an important, specific, and articulated
public interest goal that is within ICANN's mission and consistent with abalanced application of ICANN's core values as defined in ICANN's Bylaws.
(v)“Working Group” means representatives of the Applicable
Registry Operators and other members of the community that the Registry
Stakeholders Group appoints, from time to time, to serve as a working group
to consult on amendments to the Applicable Registry Agreements (excluding
bilateral amendments pursuant to Section 7.6(i)).
(k)
Notwithstanding anything in this Section 7.6 to the contrary, (i) if
Registry Operator provides evidence to ICANN's reasonable satisfaction that the Approved
Amendment would materially increase the cost of providing Registry Services, then ICANN
will allow up to one-hundred eighty (180) calendar days for Approved Amendment tobecome effective with respect to Registry Operator, and (ii) no Approved Amendment
adopted pursuant to Section 7.6 shall become effective with respect to Registry Operator if
Registry Operator provides ICANN with an irrevocable notice of termination pursuant to
Section 4.4(b).

30

7.7

Negotiation Process.

(a)
If either the Chief Executive Officer of ICANN (“CEO”) or the
Chairperson of the Registry Stakeholder Group (“Chair”) desires to discuss any revision(s)to this Agreement, the CEO or Chair, as applicable, shall provide written notice to the otherperson, which shall set forth in reasonable detail the proposed revisions to this Agreement(a “Negotiation Notice”). Notwithstanding the foregoing, neither the CEO nor the Chair may(i) propose revisions to this Agreement that modify any Consensus Policy then existing, (ii)
propose revisions to this Agreement pursuant to this Section 7.7 on or before June 30,
2014, or (iii) propose revisions or submit a Negotiation Notice more than once during any
twelve (12) month period beginning on July 1, 2014.
(b)
Following receipt of the Negotiation Notice by either the CEO or the
Chair, ICANN and the Working Group (as defined in Section 7.6) shall consult in good faithnegotiations regarding the form and substance of the proposed revisions to thisAgreement, which shall be in the form of a proposed amendment to this Agreement (the“Proposed Revisions”), for a period of at least ninety (90) calendar days (unless aresolution is earlier reached) and attempt to reach a mutually acceptable agreement
relating to the Proposed Revisions (the “Discussion Period”).
(c)If, following the conclusion of the Discussion Period, an agreement isreached on the Proposed Revisions, ICANN shall post the mutually agreed Proposed
Revisions on its website for public comment for no less than thirty (30) calendar days (the“Posting Period”) and provide notice of such revisions to all Applicable Registry Operatorsin accordance with Section 7.9. ICANN and the Working Group will consider the publiccomments submitted on the Proposed Revisions during the Posting Period (includingcomments submitted by the Applicable Registry Operators). Following the conclusion of
the Posting Period, the Proposed Revisions shall be submitted for Registry Operator
Approval (as defined in Section 7.6) and approval by the ICANN Board of Directors. If suchapprovals are obtained, the Proposed Revisions shall be deemed an Approved Amendment(as defined in Section 7.6) by the Applicable Registry Operators and ICANN, and shall beeffective and deemed an amendment to this Agreement upon sixty (60) calendar days
notice from ICANN to Registry Operator.
(d)If, following the conclusion of the Discussion Period, an agreement is
not reached between ICANN and the Working Group on the Proposed Revisions, either the
CEO or the Chair may provide the other person written notice (the “Mediation Notice”)
requiring each party to attempt to resolve the disagreements related to the Proposed
Revisions through impartial, facilitative (non-evaluative) mediation in accordance with theterms and conditions set forth below. In the event that a Mediation Notice is provided,
ICANN and the Working Group shall, within fifteen (15) calendar days thereof,
simultaneously post the text of their desired version of the Proposed Revisions and aposition paper with respect thereto on ICANN’s website.
(i)
The mediation shall be conducted by a single mediator selectedby the parties. If the parties cannot agree on a mediator within fifteen (15)31calendar days following receipt by the CEO or Chair, as applicable, of theMediation Notice, 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 withgeneral knowledge of contract law, who has no ongoing business relationshipwith 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 termof the mediation, an employee, partner, executive officer, director, or security
holder of ICANN or an Applicable Registry Operator. If such confirmation is
not provided by the appointed mediator, then a replacement mediator shallbe appointed pursuant to this Section 7.7(d)(i).
(ii)
The mediator shall conduct the mediation in accordance withthe rules and procedures for facilitative mediation that he or she determines
following consultation with the parties. The parties shall discuss the disputein good faith and attempt, with the mediator’s assistance, to reach anamicable resolution of 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.
(iv)
If an agreement is reached during the mediation, ICANN shallpost the mutually agreed Proposed Revisions on its website for the Posting
Period and provide notice to all Applicable Registry Operators in accordancewith Section 7.9. ICANN and the Working Group will consider the publiccomments submitted on the agreed Proposed Revisions during the Posting
Period (including comments submitted by the Applicable Registry
Operators). Following the conclusion of the Posting Period, the Proposed
Revisions shall be submitted for Registry Operator Approval and approval by
the ICANN Board of Directors. If such approvals are obtained, the Proposed
Revisions shall be deemed an Approved Amendment (as defined in Section
7.6) by the Applicable Registry Operators and ICANN, and shall be effective
and deemed an amendment to this Agreement upon sixty (60) calendar days
notice from ICANN to Registry Operator.
(v)
If the parties have not resolved the dispute for any reason by
the date that is ninety (90) calendar days following receipt by the CEO or
Chair, as applicable, of the Mediation Notice, the mediation shall
automatically terminate (unless extended by agreement of the parties). The
mediator shall deliver to the parties a definition of the issues that could beconsidered in future arbitration, if invoked. Those issues are subject to thelimitations set forth in Section 7.7(e)(ii) below.
(e)If, following mediation, ICANN and the Working Group have notreached an agreement on the Proposed Revisions, either the CEO or the Chair may provide
32the other person written notice (an “Arbitration Notice”) requiring ICANN and theApplicable Registry Operators to resolve the dispute through binding arbitration inaccordance with the arbitration provisions of Section 5.2, subject to the requirements andlimitations of this Section 7.7(e).
(i)
If an Arbitration Notice is sent, the mediator’s definition ofissues, along with the Proposed Revisions (be those from ICANN, theWorking Group or both) shall be posted for public comment on ICANN’s
website for a period of no less than thirty (30) calendar days. ICANN and theWorking Group will consider the public comments submitted on the
Proposed Revisions during the Posting Period (including comments
submitted by the Applicable Registry Operators), and information regarding
such comments and consideration shall be provided to a three (3) person
arbitrator panel. Each party may modify its Proposed Revisions before andafter the Posting Period. The arbitration proceeding may not commence
prior to the closing of such public comment period, and ICANN may
consolidate all challenges brought by registry operators (including Registry
Operator) into a single proceeding. Except as set forth in this Section 7.7, thearbitration shall be conducted pursuant to Section 5.2.
(ii)
No dispute regarding the Proposed Revisions may besubmitted for arbitration to the extent the subject matter of the Proposed
Revisions (i) relates to Consensus Policy, (ii) falls within the subject matter
categories set forth in Section 1.2 of Specification 1, or (iii) seeks to amend
any of the following provisions or Specifications of this Agreement: Articles
1, 3 and 6; Sections 2.1, 2.2, 2.5, 2.7, 2.9, 2.10, 2.16, 2.17, 2.19, 4.1, 4.2, 7.3, 7.6,
7.7, 7.8, 7.10, 7.11, 7.12, 7.13, 7.14, 7.16; Section 2.8 and Specification 7 (butonly to the extent such Proposed Revisions seek to implement an RPM notcontemplated by Sections 2.8 and Specification 7); Exhibit A; andSpecifications 1, 4, 6, 10 and 11.
(iii)
The mediator will brief the arbitrator panel regarding ICANN
and the Working Group’s respective proposals relating to the Proposed
Revisions.
(iv)
No amendment to this Agreement relating to the Proposed
Revisions may be submitted for arbitration by either the Working Group or
ICANN, unless, in the case of the Working Group, the proposed amendment
has received Registry Operator Approval and, in the case of ICANN, theproposed amendment has been approved by the ICANN Board of Directors.
(v)
In order for the arbitrator panel to approve either ICANN or
the Working Group’s proposed amendment relating to the Proposed
Revisions, the arbitrator panel must conclude that such proposed
amendment is consistent with a balanced application of ICANN’s core values(as described in ICANN’s Bylaws) and reasonable in light of the balancing of33

the costs and benefits to the business interests of the Applicable Registry
Operators and ICANN (as applicable), and the public benefit sought to beachieved by the Proposed Revisions as set forth in such amendment. If thearbitrator panel concludes that either ICANN or the Working Group’s
proposed amendment relating to the Proposed Revisions meets the foregoingstandard, such amendment shall be effective and deemed an amendment tothis Agreement upon sixty (60) calendar days notice from ICANN to Registry
Operator and deemed an Approved Amendment hereunder.
(f)With respect to an Approved Amendment relating to an amendment
proposed by ICANN, Registry may apply in writing to ICANN for an exemption from such
amendment pursuant to the provisions of Section 7.6.
(g)
Notwithstanding anything in this Section 7.7 to the contrary, (a) if
Registry Operator provides evidence to ICANN's reasonable satisfaction that the Approved
Amendment would materially increase the cost of providing Registry Services, then ICANN
will allow up to one-hundred eighty (180) calendar days for the Approved Amendment tobecome effective with respect to Registry Operator, and (b) no Approved Amendment
adopted pursuant to Section 7.7 shall become effective with respect to Registry Operator if
Registry Operator provides ICANN with an irrevocable notice of termination pursuant to
Section 4.4(b).
7.8
No Third-Party Beneficiaries. This Agreement will not be construed tocreate any obligation by either ICANN or Registry Operator to any non-party to thisAgreement, including any registrar or registered name holder.
7.9
General Notices. Except for notices pursuant to Sections 7.6 and 7.7, allnotices to be given under or in relation to this Agreement will be given either (i) in writingat 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. All notices under Sections 7.6
and 7.7 shall be given by both posting of the applicable information on ICANN’s web site
and transmission of such information to Registry Operator by electronic mail. Any change
in the contact information for notice below will be given by the party within thirty (30)
calendar days of such change. Other than notices under Sections 7.6 or 7.7, any noticerequired by this Agreement will 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 befollowed by a copy sent by regular postal mail service within three (3) calendar days. Any
notice required by Sections 7.6 or 7.7 will be deemed to have been given whenelectronically posted on ICANN’s website and upon confirmation of receipt by the email
server. In the event other means of notice become practically achievable, such as notice via
a secure website, the parties will work together to implement such notice means under thisAgreement.

34

If to ICANN, addressed to:Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
USA
Telephone: +1-310-301-5800
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:[________________][________________][________________]
Telephone:With a Required Copy to:
Email: (As specified from time to time.)
7.10 Entire Agreement. This Agreement (including those specifications anddocuments incorporated by reference to URL locations which form a part of it) constitutes
the entire agreement of the parties hereto pertaining to the operation of the TLD andsupersedes all prior agreements, understandings, negotiations and discussions, whether
oral or written, between the parties on that subject.
7.11 English Language Controls. Notwithstanding any translated version of thisAgreement 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 madeunder this Agreement shall be in the English language.
7.12 Ownership Rights. Nothing contained in this Agreement shall be construed
as (a) establishing or granting to Registry Operator any property ownership rights orinterests of Registry Operator in the TLD or the letters, words, symbols or other charactersmaking up the TLD string, or (b) affecting any existing intellectual property or ownershiprights of Registry Operator.
7.13 Severability; Conflicts with Laws. 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 of 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 good35

faith to modify this Agreement so as to effect the original intent of the parties as closely as
possible. ICANN and the Working Group will mutually cooperate to develop an ICANN
procedure for ICANN’s review and consideration of alleged conflicts between applicablelaws and non-WHOIS related provisions of this Agreement. Until such procedure isdeveloped and implemented by ICANN, ICANN will review and consider alleged conflicts
between applicable laws and non-WHOIS related provisions of this Agreement in a manner
similar to ICANN’s Procedure For Handling WHOIS Conflicts with Privacy Law.
7.14 Court Orders. ICANN will respect any order from a court of competentjurisdiction, including any orders from any jurisdiction where the consent or non-objectionof the government was a requirement for the delegation of the TLD. Notwithstanding anyother provision of this Agreement, ICANN’s implementation of any such order will not be abreach of this Agreement
7.15

Confidentiality(a)
Subject to Section 7.15(c), during the Term and for a period of three(3) years thereafter, each party shall, and shall cause its and its Affiliates’ officers, directors,
employees and agents to, keep confidential and not publish or otherwise disclose to any
third party, directly or indirectly, any information that is, and the disclosing party has
marked as, or has otherwise designated in writing to the receiving party as, “confidential
trade secret,” “confidential commercial information” or “confidential financial information”(collectively, “Confidential Information”), except to the extent such disclosure is permitted
by the terms of this Agreement.
(b)
The confidentiality obligations under Section 7.15(a) shall not apply
to any Confidential Information that (i) is or hereafter becomes part of the public domain
by public use, publication, general knowledge or the like through no fault of the receiving
party in breach of this Agreement, (ii) can be demonstrated by documentation or othercompetent proof to have been in the receiving party’s possession prior to disclosure by thedisclosing party without any obligation of confidentiality with respect to such information,(iii) is subsequently received by the receiving party from a third party who is not bound by
any obligation of confidentiality with respect to such information, (iv) has been publishedby a third party or otherwise enters the public domain through no fault of the receiving
party, or (v) can be demonstrated by documentation or other competent evidence to havebeen independently developed by or for the receiving party without reference to thedisclosing party’s Confidential Information.
(c)
Each party shall have the right to disclose Confidential Information to
the extent that such disclosure is (i) made in response to a valid order of a court ofcompetent jurisdiction or, if in the reasonable opinion of the receiving party’s legal counsel,
such disclosure is otherwise required by applicable law; provided, however, that thereceiving party shall first have given notice to the disclosing party and given the disclosing
party a reasonable opportunity to quash such order or to obtain a protective order or
confidential treatment order requiring that the Confidential Information that is the subjectof such order or other applicable law be held in confidence by such court or other third36

party recipient, unless the receiving party is not permitted to provide such notice undersuch order or applicable law, or (ii) made by the receiving party or any of its Affiliates to its
or their attorneys, auditors, advisors, consultants, contractors or other third parties for use
by such person or entity as may be necessary or useful in connection with the performanceof the activities under this Agreement, provided that such third party is bound by
confidentiality obligations at least as stringent as those set forth herein, either by writtenagreement or through professional responsibility standards.
[Note: The following section is applicable to intergovernmental organizations or
governmental entities only.]
7.16 Special Provision Relating to Intergovernmental Organizations orGovernmental Entities.
(a)
ICANN acknowledges that Registry Operator is an entity subject topublic international law, including international treaties applicable to Registry Operator(such public international law and treaties, collectively hereinafter the “Applicable Laws”).
Nothing in this Agreement and its related specifications shall be construed or interpreted
to require Registry Operator to violate Applicable Laws or prevent compliance therewith.
The Parties agree that Registry Operator’s compliance with Applicable Laws shall notconstitute a breach of this Agreement.
(b)
In the event Registry Operator reasonably determines that any
provision of this Agreement and its related specifications, or any decisions or policies of
ICANN referred to in this Agreement, including but not limited to Temporary Policies andConsensus Policies (such provisions, specifications and policies, collectively hereinafter,“ICANN Requirements”), may conflict with or violate Applicable Law (hereinafter, a“Potential Conflict”), Registry Operator shall provide detailed notice (a “Notice”) of such
Potential Conflict to ICANN as early as possible and, in the case of a Potential Conflict with aproposed Consensus Policy, no later than the end of any public comment period on suchproposed Consensus Policy. In the event Registry Operator determines that there isPotential Conflict between a proposed Applicable Law and any ICANN Requirement,
Registry Operator shall provide detailed Notice of such Potential Conflict to ICANN as earlyas possible and, in the case of a Potential Conflict with a proposed Consensus Policy, no
later than the end of any public comment period on such proposed Consensus Policy.
(c)
As soon as practicable following such review, the parties shall attempt
to resolve the Potential Conflict by mediation pursuant to the procedures set forth in
Section 5.1. In addition, Registry Operator shall use its best efforts to eliminate orminimize any impact arising from such Potential Conflict between Applicable Laws and any
ICANN Requirement. If, following such mediation, Registry Operator determines that the
Potential Conflict constitutes an actual conflict between any ICANN Requirement, on the
one hand, and Applicable Laws, on the other hand, then ICANN shall waive compliance withsuch ICANN Requirement (provided that the parties shall negotiate in good faith on acontinuous basis thereafter to mitigate or eliminate the effects of such noncompliance on
ICANN), unless ICANN reasonably and objectively determines that the failure of Registry37

Operator to comply with such ICANN Requirement would constitute a threat to the Security
and Stability of Registry Services, the Internet or the DNS (hereinafter, an “ICANN
Determination”). Following receipt of notice by Registry Operator of such ICANN
Determination, Registry Operator shall be afforded a period of ninety (90) calendar days toresolve such conflict with an Applicable Law. If the conflict with an Applicable Law is not
resolved to ICANN’s complete satisfaction during such period, Registry Operator shall havethe option to submit, within ten (10) calendar days thereafter, the matter to binding
arbitration as defined in subsection (d) below. If during such period, Registry Operator
does not submit the matter to arbitration pursuant to subsection (d) below, ICANN may,upon notice to Registry Operator, terminate this Agreement with immediate effect.
(d)
If Registry Operator disagrees with an ICANN Determination, Registry
Operator may submit the matter to binding arbitration pursuant to the provisions ofSection 5.2, except that the sole issue presented to the arbitrator for determination will bewhether or not ICANN reasonably and objectively reached the ICANN Determination. For
the purposes of such arbitration, ICANN shall present evidence to the arbitrator supporting
the ICANN Determination. If the arbitrator determines that ICANN did not reasonably andobjectively reach the ICANN Determination, then ICANN shall waive Registry Operator’scompliance with the subject ICANN Requirement. If the arbitrators or pre-arbitral referee,
as applicable, determine that ICANN did reasonably and objectively reach the ICANN
Determination, then, upon notice to Registry Operator, ICANN may terminate thisAgreement with immediate effect.
(e)
Registry Operator hereby represents and warrants that, to the best of
its knowledge as of the date of execution of this Agreement, no existing ICANN
Requirement conflicts with or violates any Applicable Law.
(f)
Notwithstanding any other provision of this Section 7.16, following an
ICANN Determination and prior to a finding by an arbitrator pursuant to Section 7.16(d)above, ICANN may, subject to prior consultations with Registry Operator, take suchreasonable technical measures as it deems necessary to ensure the Security and Stability ofRegistry Services, the Internet and the DNS. These reasonable technical measures shall betaken by ICANN on an interim basis, until the earlier of the date of conclusion of thearbitration procedure referred to in Section 7.16(d) above or the date of complete
resolution of the conflict with an Applicable Law. In case Registry Operator disagrees withsuch technical measures taken by ICANN, Registry Operator may submit the matter tobinding arbitration pursuant to the provisions of Section 5.2 above, during which process
ICANN may continue to take such technical measures. In the event that ICANN takes suchmeasures, Registry Operator shall pay all costs incurred by ICANN as a result of taking suchmeasures. In addition, in the event that ICANN takes such measures, ICANN shall retain
and may enforce its rights under the Continued Operations Instrument and Alternative
Instrument, as applicable.
*****

38

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:_____________________________[_____________]
President and CEO
Date:[Registry Operator]

By:_____________________________[____________][____________]
Date:

39

EXHIBIT A
Approved Services
The ICANN gTLD Applicant Guidebook (located at
http://newgtlds.icann.org/en/applicants/agb) and the RSEP specify processes forconsideration 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 theTLD
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 be40

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

41

SPECIFICATION 1
CONSENSUS POLICIES AND TEMPORARY POLICIES SPECIFICATION
1.

Consensus Policies.
1.1.

“Consensus Policies” are those policies established (1) pursuant to theprocedure 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 berevised 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 shallrelate 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 theInternet or Domain Name System (“DNS”);
1.2.2 functional and performance specifications for the provision ofRegistry 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 (asopposed 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 toregistry operations and the use of registry and registrar data in theevent 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 byregistries or registrars;
421.3.3 reservation of registered names in the TLD that may not be registeredinitially 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 fromregistration); and1.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 theRegistry 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 andthat 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 andshall 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
43the Board believes such Temporary Policy should receive theconsensus 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 theone (1) year period expires or, if during such one (1) year period, theTemporary Policy does not become a Consensus Policy and is not
reaffirmed by the Board, Registry Operator shall no longer berequired to comply with or implement such Temporary Policy.
3.

Notice and Conflicts. Registry Operator shall be afforded a reasonable period oftime 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 andConsensus Policies or any Temporary Policy, the Consensus Polices or Temporary
Policy shall control, but only with respect to subject matter in conflict.

44

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 inPart B, will be included in any data escrow agreement between Registry Operator and theEscrow 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 thatare not contradictory or intended to subvert the required terms provided below.
PART A – TECHNICAL SPECIFICATIONS
1.

2.

3.

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 notreflected in the last previous Full or Differential Deposit, as the case may be.
Each Differential Deposit will contain all database transactions since theprevious 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).

Schedule for Deposits. Registry Operator will submit a set of escrow files on adaily 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.

Escrow Format Specification.
3.1.

Deposit’s Format. Registry objects, such as domains, contacts, nameservers, registrars, etc. will be compiled into a file constructed as describedin draft-arias-noguchi-registry-data-escrow, see Part A, Section 9, reference 1of 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
45

optional; Registry Operator will include those elements in the Deposits ifthey are available. If not already an RFC, Registry Operator will use the mostrecent 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.

4.

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.1of this Specification. ICANN and the respective Registry Operator shall work
together to agree on such new objects’ data escrow specifications.

Processing of Deposit files. The use of compression is recommended in order toreduce 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 asper OpenPGP Message Format - RFC 4880, see Part A, Section 9, reference 3 of thisSpecification. Acceptable algorithms for Public-key cryptography, Symmetric-key
cryptography, Hash and Compression are those enumerated in RFC 4880, notmarked as deprecated in OpenPGP IANA Registry, see Part A, Section 9, reference 4of this Specification, that are also royalty-free. The process to follow for the data filein original text format is:(1)

The XML file of the deposit as described in Part A, Section 9, reference 1 ofthis 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 tarballfile 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 islarger than the file size limit agreed with the escrow agent. Every part of a46

split file, or the whole file if not split, will be called a processed file in thissection.

5.

(5)

A digital signature file will be generated for every processed file using theRegistry 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 becompressed 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 fileusing the procedure described in Part A, Section 8 of this Specification.

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, theASCII-compatible form (A-Label) must be used;

5.2.

{YYYY-MM-DD} is replaced by the date corresponding to the time used as atimeline 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:

5.4.

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

{#} 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”.
47

5.5.

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

{ext} is replaced by “sig” if it is a digital signature file of thequasi-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 amail 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 indraft-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 of thisSpecification (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 beeninspected by Registry Operator and is complete and accurate. The preparation andsubmission 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 theInterface Specification at the Effective Date. Registry Operator may at its election
use newer versions of the Interface Specification after the Effective Date. Once theInterface Specification is published as an RFC, Registry Operator will implement thatversion 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 theformat defined in Part A, Section 9, reference 1 of this Specification.

48

(5)

The data escrow agent extended verification process, as defined below inreference 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

49

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, andall 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), theEscrow 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 theterm of the Registry Agreement any Deposit is released from escrow to ICANN, any
intellectual property rights held by Registry Operator in the Deposits willautomatically be licensed to ICANN or to a party designated in writing by ICANN ona 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 andmaintain the Deposits in a secure, locked, and environmentally safe facility, which isaccessible only to authorized representatives of Escrow Agent, (ii) protect the
integrity and confidentiality of the Deposits using commercially reasonablemeasures and (iii) keep and safeguard each Deposit for one (1) year. ICANN andRegistry 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 andmaintenance requirements of this Specification 2 from time to time.
If Escrow Agent receives a subpoena or any other order from a court or otherjudicial tribunal pertaining to the disclosure or release of the Deposits, Escrow
Agent will promptly notify the Registry Operator and ICANN unless prohibited bylaw. After notifying the Registry Operator and ICANN, Escrow Agent shall allow
50

sufficient time for Registry Operator or ICANN to challenge any such order, whichshall 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 tosupport 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 tocomply 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 toeffect 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 and7.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 Agentand 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 ofthis Specification from Escrow Agent of failed verification of the latest escrowdeposit for a specific date or a notification of a missing deposit, and thenotification 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 Specificationfrom 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 escrowdeposits 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 ofsuch Differential Deposit; or

51

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 theworld; or

6.6.

Registry Operator has experienced a failure of critical registry functions and
ICANN has asserted its rights pursuant to Section 2.13 of the Agreement; or

6.7.

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

6.8.

pursuant to Contractual and Operational Compliance Audits as specified
under Section 2.11 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.

8.

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 indraft-lozano-icann-registry-interfaces, see Part A, Section 9, reference 5 ofthis 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 Agentmust 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 thenon-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 theverification procedures and deliver such fixes to Escrow Agent as promptly
as possible.

Amendments. Escrow Agent and Registry Operator shall amend the terms of theEscrow Agreement to conform to this Specification 2 within ten (10) calendar daysof 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 shallcontrol.

52

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 andall claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and anyother expenses whatsoever, including reasonable attorneys’ fees and costs, that may
be asserted by a third party against any Indemnitee in connection with themisrepresentation, negligence or misconduct of Escrow Agent, its directors, officers,
agents, employees and contractors.

53

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 theconfidentiality of the information reported until three (3) months after the end of themonth to which the reports relate. Unless set forth in this Specification 3, any reference toa specific time refers to Coordinated Universal Time (UTC). Monthly reports shall consistof 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
#
01

Field name

Description

registrar-nameRegistrar’s full corporate name as registered with
IANA

02

iana-id

For cases where the registry operator acts asregistrar (i.e., without the use of an ICANN
accredited registrar) either 9998 or 9999 should
be used depending on registration type (asdescribed in Specification 5), otherwise thesponsoring 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
purged04

total-nameservers

total name servers (either host objects or nameserver hosts as domain name attributes)
associated with domain names registered for the
TLD in any EPP status but pendingCreate thathave 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 reported54

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 bereported 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 initial55

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., notin EPP pendingRenew status) either automaticallyor by command with a new renewal period of one(1) year (and not deleted within the renew orauto-renew grace period). A transaction must bereported in the month the renew or auto-renew
grace period ends.

16

net-renews-2-yr

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

17

net-renews-3-yr

number of domains successfully renewed (i.e., notin EPP pendingRenew status) either automaticallyor 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 orauto-renew grace period ends.

18

net-renews-4-yr

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

19

net-renews-5-yr

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

20

net-renews-6-yr

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

net-renews-7-yr

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

22

net-renews-8-yr

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

23

net-renews-9-yr

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

24

net-renews-10-yr

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

25

transfer-gaining-successful

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

26

transfer-gaining-nacked

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

27

transfer-losing-successful

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

28

transfer-losing-nacked

number of domain transfers initiated by anotherregistrar that this registrar rejected (e.g., EPP
57

transfer op="reject")29

transfer-disputed-won

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

30

transfer-disputed-lostnumber of transfer disputes this registrar lost
(reported in the month where the determination
happened)

31transfer-disputed-nodecision

number of transfer disputes involving thisregistrar 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 bereported 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 bereported 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 theregistrar failed to submit it36

agp-exemption-requests

total number of AGP (add grace period) exemption
requests37

agp-exemptions-granted

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

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 theones 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 an58

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
period02

zfa-passwords

number of active zone file access passwords atthe end of the reporting period; "CZDS" may be
used instead of the number of active zone fileaccess passwords, if the Centralized Zone Data
Service (CZDS) is used to provide the zone fileto the end user03

whois-43-queries

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

web-whois-queries

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

05

searchable-whois-queries

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

dns-udp-queries-received

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

dns-udp-queries-responded

number of DNS queries received over UDP
transport that were responded during thereporting period08

dns-tcp-queries-received

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

dns-tcp-queries-responded

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

10

srs-dom-checknumber of SRS (EPP and any other interface)domain name “check” requests responded
during the reporting period11

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
59

Field #Field Name

Description
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 deliveringa restore report responded during the reporting
period16

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 approvetransfers responded during the reporting
period18

srs-dom-transfer-cancel

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

srs-dom-transfer-query

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

20

srs-dom-transfer-reject

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

srs-dom-transfer-request

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

srs-dom-update

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

23

srs-host-checknumber of SRS (EPP and any other interface)
host “check” requests responded during thereporting period24

srs-host-create

number of SRS (EPP and any other interface)
host “create” requests responded during the60Field #Field Name

Description
reporting period25

srs-host-delete

number of SRS (EPP and any other interface)
host “delete” requests responded during thereporting period26

srs-host-info

number of SRS (EPP and any other interface)
host “info” requests responded during thereporting period27

srs-host-update

number of SRS (EPP and any other interface)
host “update” requests responded during thereporting period28

srs-cont-checknumber of SRS (EPP and any other interface)contact “check” requests responded during thereporting period29

srs-cont-create

number of SRS (EPP and any other interface)contact “create” requests responded during thereporting period30

srs-cont-delete

number of SRS (EPP and any other interface)contact “delete” requests responded during thereporting period31

srs-cont-info

number of SRS (EPP and any other interface)contact “info” requests responded during thereporting 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 atransfer 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 period37

srs-cont-update

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

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

62

SPECIFICATION 4REGISTRATION DATA PUBLICATION SERVICES
1.

Registration Data Directory Services. Until ICANN requires a different protocol,
Registry Operator will operate a WHOIS service available via port 43 in accordancewith 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, andupon 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 domainname 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 ispublished, 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 operationof 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 ofRegistry 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, followedby the value.

1.3.

For fields where more than one value exists, multiple key/value pairs withthe 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 andregistrant 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
63

WHOIS Server: whois.example.tld
Referral URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00ZCreation 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: A1A1A1Registrant 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 STREETTech City: ANYTOWNTech State/Province: AP
Tech Postal Code: A1A1A1Tech Country: EX
Tech Phone: +1.1235551234
64

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”.
65

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 andorganizational names, address, street, city, state/province, postal code,
country, telephone and fax numbers (the extension will be provided as aseparate field as shown above), email addresses, date and times should
conform to the mappings specified in EPP RFCs 5730-5734 so that thedisplay 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 thespecification 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 thefollowing fields: domain name, contacts and registrant’s name, andcontact 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 thefollowing 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, atleast, 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
66

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) toa web page designated by ICANN containing WHOIS policy and educational
materials.
2.

Zone File Access
2.1.

Third-Party Access2.1.1 Zone File Access Agreement. Registry Operator will enter into anagreement with any Internet user, which will allow such user toaccess an Internet host server or servers designated by Registry
Operator and download zone file data. The agreement will bestandardized, 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 thisSpecification and do so using the file format described in Section 2.1.4of this Specification. Notwithstanding the foregoing, (a) the CZDA
Provider may reject the request for access of any user that does notsatisfy 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 theterms of Section 2.1.5. below; and, (c) Registry Operator may revoke
access of any user if Registry Operator has evidence to support thatthe user has violated the terms of Section 2.1.5 below.
2.1.2 Credentialing Requirements. Registry Operator, through thefacilitation of the CZDA Provider, will request each user to provide itwith 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
67

a copy of the top-level domain zone files, and any associatedcryptographic checksum files no more than once per 24 hour periodusing SFTP, or other data transport and access protocols that may beprescribed 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 thestandard 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 tocontinue 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 arecord across a line boundary.

14.

No use of comments.

15.

No blank lines.
68

16.

The SOA record should be present at the top and (duplicatedat) 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, withall 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 thezone file for lawful purposes; provided that (a) user takes all
reasonable steps to protect against unauthorized access to, use of, anddisclosure 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 bye-mail, telephone, facsimile, postal mail, SMS, and wireless alerts ofmass 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 atleast daily. Zone files will include SRS data committed as close as possible to
00:00:00 UTC.

69

2.4.

3.

Emergency Operator Access. Registry Operator shall provide bulk accessto 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.

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 namerepository 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 ofregistrar.
3.1.2 Format. The data will be provided in the format specified inSpecification 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 asof 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 thedomain 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 for70

download by ICANN in the same manner as the data specified in Section 3.1of this Specification.

71

SPECIFICATION 5SCHEDULE OF RESERVED NAMES
Except to the extent that ICANN otherwise expressly authorizes in writing, and subject tothe 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 otherlevels 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 orentity 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 andrenew such name without use of an ICANN accredited registrar, which will not be
considered Transactions for purposes of Section 6.1 of the Agreement.

2.

Two-character labels. All two-character ASCII labels shall be withheld fromregistration or allocated to Registry Operator at the second level within the TLD.
Such labels may not be activated in the DNS, and may not be released forregistration to any person or entity other than Registry Operator, provided thatsuch two-character label strings may be released to the extent that Registry
Operator reaches agreement with the related government and country-code
manager of the string as specified in the ISO 3166-1 alpha-2 standard. The Registry
Operator may also propose the release of these reservations based on its
implementation of measures to avoid confusion with the corresponding country
codes, subject to approval by ICANN. Upon conclusion of Registry Operator’s
designation as operator of the registry for the TLD, all such labels 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 consideredTransactions for purposes of Section 6.1 of the Agreement.

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,
72

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 suchwithheld 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 forpurposes of Section 6.1 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 registryfunctions. For the avoidance of doubt, Registry Operator is required
to activate the ASCII label NIC pursuant to Section 3.1 of thisSpecification 3.
3.2.

Registry Operator may activate in the DNS at All Levels up to one hundred(100) names (plus their IDN variants, where applicable) necessary for theoperation or the promotion of the TLD. Registry Operator must act as theRegistered Name Holder of such names as that term is defined in thethen-current ICANN Registrar Accreditation Agreement (RAA). These
activations will be considered Transactions for purposes of Section 6.1 of theAgreement. Registry Operator must either (i) register such names through an
ICANN accredited registrar; or (ii) self-allocate such names and with respect
to those names submit to and be responsible to ICANN for compliance withICANN Consensus Policies and the obligations set forth in Subsections 3.7.7.1
through 3.7.7.12 of the then-current RAA (or any other replacement clausesetting out the terms of the registration agreement between a registrar and aregistered name holder). If Registry Operator chooses option (ii) above, it
shall identify these transactions using Registrar ID 9998. At Registry
Operator’s discretion and in compliance with all other terms of thisAgreement, including the RPMs set forth in Specification 7, such names may
be released for registration to another person or entity.

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 2.6 of the Agreement. Such names may not be
activated in the DNS, but may be released for registration to Registry73

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 namesthat 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 2.6 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
6.1 of the Agreement.
3.4.

4.

Effective upon the conclusion of the No-Activation Period specified in Section
6.1 of Specification 6, 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 notavailable for registration in the TLD or is otherwise inconsistent with theregistration 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 (i) be
considered a Transaction for purposes of Section 6.1 of the Agreement, (ii)count towards the one hundred domain names available to Registry Operator
under Section 3.2 of this Specification 5, or (iii) adversely affect Registry
Operator’s qualification as a .BRAND TLD pursuant to Specification 13(.BRAND TLD Provisions) hereto (as applicable).

Country and Territory Names. The country and territory names (including their
IDN variants, where applicable) contained in the following internationallyrecognized 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 nameEuropean Union<http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3
166-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

74

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, whereapplicable) may be released to the extent that Registry Operator reaches agreementwith the applicable government(s). Registry Operator must not activate such namesin the DNS; provided, that Registry Operator may propose the release of thesereservations, subject to review by ICANN’s Governmental Advisory Committee andapproval by ICANN. Upon conclusion of Registry Operator’s designation as operatorof 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 ofSection 6.1 of the Agreement.
5.

International Olympic Committee; International Red Cross and Red Crescent
Movement. As instructed from time to time by ICANN, the names (including their
IDN variants, where applicable) relating to the International Olympic Committee,
International Red Cross and Red Crescent Movement listed at
http://www.icann.org/en/resources/registries/reserved shall be withheld fromregistration or allocated to Registry Operator at the second level within the TLD.
Additional International Olympic Committee, International Red Cross and Red
Crescent Movement names (including their IDN variants) may be added to the list
upon ten (10) calendar days notice from ICANN to Registry Operator. Such names
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, all such names
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 consideredTransactions for purposes of Section 6.1 of the Agreement.

6.

Intergovernmental Organizations. As instructed from time to time by ICANN,
Registry Operator will implement the protections mechanism determined by the
ICANN Board of Directors relating to the protection of identifiers forIntergovernmental Organizations. A list of reserved names for this Section 6 isavailable at http://www.icann.org/en/resources/registries/reserved. Additional
names (including their IDN variants) may be added to the list upon ten (10)calendar days notice from ICANN to Registry Operator. Any such protected
identifiers for Intergovernmental Organizations 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 theregistry for the TLD, all such protected identifiers shall be transferred as specified
by ICANN. Registry Operator may self-allocate and renew such names without use
75

of an ICANN accredited registrar, which will not be considered Transactions forpurposes of Section 6.1 of the Agreement.

76

SPECIFICATION 6REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS
1.

Standards Compliance
1.1.

DNS. Registry Operator shall comply with relevant existing RFCs and thosepublished 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 and6891. 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 thosepublished 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 theirsuccessors, 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 childdomain 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 ofregistrants’ 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 athttps://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s
Registry Services making use of data obtained via DNS responses.
77

2.

1.4.

IDN. If the Registry Operator offers Internationalized Domain Names(“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and theirsuccessors. Registry Operator shall comply with the ICANN IDN Guidelinesat <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 gluerecords 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 definedin 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 willingto 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 achange 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.

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 theregistry critical to the following tasks: the receipt of data from registrars
concerning registrations of domain names and name servers; provision toregistrars of status information relating to the zone servers for the TLD;
dissemination of TLD zone files; operation of the registry DNS servers; anddissemination of contact and other information concerning domain nameserver registrations in the TLD as required by this Agreement; (b) other78

products or services that the Registry Operator is required to provide
because of the establishment of a Consensus Policy as defined inSpecification 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 scopeof (a), (b) or (c) above.
2.2.

3.

Wildcard Prohibition. For domain names which are either not registered,or the registrant has not supplied valid records such as NS records for listingin 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 DNSResources Records or using redirection within the DNS by the Registry is
prohibited. When queried for such domain names the authoritative nameservers 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.

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 theimplementation of a load balancing scheme where applicable) to ensure
continued operation in the case of technical failure (widespread or local), oran extraordinary occurrence or circumstance beyond the control of theRegistry 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 amaximum of forty-eight (48) hours following such event, depending on thetype 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 eventof 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 designationof a Registry Services continuity provider, Registry Operator shall provide
79the name and contact information for such Registry Services continuity
provider to ICANN. In the case of an extraordinary event beyond the controlof 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.

5.

6.

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 mailingaddress as well as a primary contact for handling inquiries related tomalicious conduct in the TLD, and will provide ICANN with prompt notice ofany 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.

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 often (10) years. For the avoidance of doubt, initial registrations of registerednames 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.

Name Collision Occurrence Management
6.1.

No-Activation Period. Registry Operator shall not activate any names in the
DNS zone for the Registry TLD (except for "NIC") until at least 120 calendar
days after the effective date of this agreement. Registry Operator may
allocate names (subject to subsection 6.2 below) during this period only if
Registry Operator causes registrants to be clearly informed of the inability toactivate names until the No-Activation Period ends.

6.2.

Name Collision Occurrence Assessment
6.2.1 Registry Operator shall not activate any names in the DNS zone for theRegistry TLD except in compliance with a Name Collision Occurrence
Assessment provided by ICANN regarding the Registry TLD. Registry80

Operator will either (A) implement the mitigation measures describedin its Name Collision Occurrence Assessment before activating any
second-level domain name, or (B) block those second-level domainnames for which the mitigation measures as described in the Name
Collision Occurrence Assessment have not been implemented andproceed with activating names that are not listed in the Assessment.
6.2.2 Notwithstanding subsection 6.2.1, Registry Operator may proceedwith activation of names in the DNS zone without implementation of
the measures set forth in Section 6.2.1 only if (A) ICANN determinesthat the Registry TLD is eligible for this alternative path to activationof names; and (B) Registry Operator blocks all second-level domainnames identified by ICANN and set forth at<http://newgtlds.icann.org/en/announcements-and-media/announc
ement-2-17nov13-en> as such list may be modified by ICANN from time totime. Registry Operator may activate names pursuant to thissubsection and later activate names pursuant to subsection 6.2.1.
6.2.3 The sets of names subject to mitigation or blocking pursuant to
Sections 6.2.1 and 6.2.2 will be based on ICANN analysis of DNS
information including "Day in the Life of the Internet" data
maintained by the DNS Operations, Analysis, and Research Center(DNS-OARC) <https://www.dns-oarc.net/oarc/data/ditl>.
6.2.4 Registry Operator may participate in the development by the ICANN
community of a process for determining whether and how theseblocked names may be released.
6.2.5 If ICANN determines that the TLD is ineligible for the alternative pathto activation of names, ICANN may elect not to delegate the TLD
pending completion of the final Name Collision Occurrence
Assessment for the TLD, and Registry Operator’s completion of all
required mitigation measures. Registry Operator understands that the
mitigation measures required by ICANN as a condition to activation ofnames in the DNS zone for the TLD may include, without limitation,
mitigation measures such as those described in Section 3.2 of the New
gTLD Name Collision Occurrence Management Plan approved by the
ICANN Board New gTLD Program Committee (NGPC) on 7 October
2013 as found at<http://www.icann.org/en/groups/board/documents/resolutions-n
ew-gtld-annex-1-07oct13-en.pdf>.
6.3.

Name Collision Report Handling
6.3.1 During the first two years after delegation of the TLD, Registry
Operator’s emergency operations department shall be available to81receive reports, relayed by ICANN, alleging demonstrably severe harmfrom collisions with overlapping use of the names outside of theauthoritative DNS.
6.3.2 Registry Operator shall develop an internal process for handling in an
expedited manner reports received pursuant to subsection 6.3.1
under which Registry Operator may, to the extent necessary andappropriate, remove a recently activated name from the TLD zone fora period of up to two years in order to allow the affected party tomake changes to its systems.

82

SPECIFICATION 7MINIMUM REQUIREMENTS FOR RIGHTS PROTECTION MECHANISMS
1.

Rights Protection Mechanisms. Registry Operator shall implement and adhere to
the rights protection mechanisms (“RPMs”) specified in this Specification. In
addition to such RPMs, Registry Operator may develop and implement additional
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 thisSpecification 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. Registry Operator shall
implement in accordance with requirements set forth therein each of the mandatory
RPMs set forth in the Trademark Clearinghouse as of the date hereof, as posted at
http://www.icann.org/en/resources/registries/tmch-requirements (the“Trademark Clearinghouse Requirements”), which may be revised in immaterial
respects by ICANN from time to time. Registry Operator shall not mandate that any
owner of applicable intellectual property rights use any other trademark
information aggregation, notification, or validation service in addition to or insteadof the ICANN-designated Trademark Clearinghouse. If there is a conflict between
the terms and conditions of this Agreement and the Trademark Clearinghouse
Requirements, the terms and conditions of this Agreement shall control. Registry
Operator must enter into a binding and enforceable Registry-Registrar Agreementwith at least one ICANN accredited registrar authorizing such registrar(s) to registerdomain names in the TLD as follows:a.

if Registry Operator conducts a Qualified Launch Program or is authorized by
ICANN to conduct an Approved Launch Program (as those terms are definedin the Trademark Clearinghouse Requirements), Registry Operator mustenter into a binding and enforceable Registry-Registrar Agreement with atleast one ICANN accredited registrar prior to allocating any domain names
pursuant to such Qualified Launch Program or Approved Launch Program, as
applicable;b.

if Registry Operator does not conduct a Qualified Launch Program or is not
authorized by ICANN to conduct an Approved Launch Program, Registry
Operator must enter into a binding and enforceable Registry-Registrar
Agreement with at least one ICANN accredited registrar at least thirty (30)
calendar days prior to the expiration date of the Sunrise Period (as defined in
the Trademark Clearinghouse Requirements) for the TLD; orc.

if this Agreement contains a Specification 13, Registry Operator must enter
into a binding and enforceable Registry-Registrar Agreement with at leastone ICANN accredited registrar prior to the Claims Commencement Date (asdefined in Specification 13).

83

Nothing in this Specification 7 shall limit or waive any other obligations or
requirements of this Agreement applicable to Registry Operator, including Section
2.9(a) and Specification 9.
2.

Dispute Resolution Mechanisms. Registry Operator will comply with thefollowing 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 4.3(e) of the Agreement) following a determination by any PDDRP or
RRDRP panel and to be bound by any such determination; andb.

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

84

SPECIFICATION 8CONTINUED OPERATIONS INSTRUMENT
1.

The Continued Operations Instrument shall (a) provide for sufficient financial
resources to ensure the continued operation of the critical registry functions related
to the TLD set forth in Section 6 of Specification 10 to this Agreement for a period of
three (3) years following any termination of this Agreement on or prior to the fifth
anniversary of the Effective Date or for a period of one (1) year following any
termination of this Agreement after the fifth anniversary of the Effective Date but
prior to or on the sixth (6th) anniversary of the Effective Date, and (b) be in the formof either (i) an irrevocable standby letter of credit, or (ii) an irrevocable cash escrowdeposit, each meeting the requirements set forth in item 50(b) of Attachment toModule 2 – Evaluation Questions and Criteria – of the gTLD Applicant Guidebook, as
published and supplemented by ICANN prior to the date hereof (which is hereby
incorporated by reference into this Specification 8). Registry Operator shall use its
best efforts to take all actions necessary or advisable to maintain in effect theContinued Operations Instrument for a period of six (6) years from the Effective
Date, and to maintain ICANN as a third party beneficiary thereof. If Registry
Operator elects to obtain an irrevocable standby letter of credit but the term
required above is unobtainable, Registry Operator may obtain a letter of credit witha one-year term and an “evergreen provision,” providing for annual extensions,
without amendment, for an indefinite number of additional periods until the issuingbank informs ICANN of its final expiration or until ICANN releases the letter of credit
as evidenced in writing, if the letter of credit otherwise meets the requirements set
forth in item 50(b) of Attachment to Module 2 – Evaluation Questions and Criteria –of the gTLD Applicant Guidebook, as published and supplemented by ICANN prior to
the date hereof; provided, however, that if the issuing bank informs ICANN of the
expiration of such letter of credit prior to the sixth (6th) anniversary of the Effective
Date, such letter of credit must provide that ICANN is entitled to draw the funds
secured by the letter of credit prior to such expiration. The letter of credit must
require the issuing bank to give ICANN at least thirty (30) calendar days’ notice ofany such expiration or non-renewal. If the letter of credit expires or is terminated at
any time prior to the sixth (6th) anniversary of the Effective Date, Registry Operator
will be required to obtain a replacement Continued Operations Instrument. ICANN
may draw the funds under the original letter of credit, if the replacement Continued
Operations Instrument is not in place prior to the expiration of the original letter ofcredit. Registry Operator shall provide to ICANN copies of all final documents
relating to the Continued Operations Instrument and shall keep ICANN reasonably
informed of material developments relating to the Continued Operations
Instrument. Registry Operator shall not agree to, or permit, any amendment of, or
waiver under, the Continued Operations Instrument or other documentation
relating thereto without the prior written consent of ICANN (such consent not to be
unreasonably withheld).

85

2.

If, notwithstanding the use of best efforts by Registry Operator to satisfy its
obligations under the preceding paragraph, the Continued Operations Instrument
expires or is terminated by another party thereto, in whole or in part, for any
reason, prior to the sixth anniversary of the Effective Date, Registry Operator shallpromptly (i) notify ICANN of such expiration or termination and the reasons
therefor and (ii) arrange for an alternative instrument that provides for sufficientfinancial resources to ensure the continued operation of the critical registryfunctions related to the TLD set forth in Section 6 of Specification 10 to thisAgreement for a period of three (3) years following any termination of thisAgreement on or prior to the fifth anniversary of the Effective Date or for a period ofone (1) year following any termination of this Agreement after the fifth anniversaryof the Effective Date but prior to or on the sixth (6) anniversary of the Effective Date(an “Alternative Instrument”). Any such Alternative Instrument shall be on terms
no less favorable to ICANN than the Continued Operations Instrument and shallotherwise be in form and substance reasonably acceptable to ICANN.

3.

Notwithstanding anything to the contrary contained in this Specification 8, at any
time, Registry Operator may replace the Continued Operations Instrument with an
Alternative Instrument that (i) provides for sufficient financial resources to ensure
the continued operation of the critical registry functions related to the TLD set forthin Section 6 of Specification 10 to this Agreement for a period of three (3) years
following any termination of this Agreement on or prior to the fifth anniversary of
the Effective Date or for a period one (1) year following any termination of thisAgreement after the fifth anniversary of the Effective Date but prior to or on thesixth (6) anniversary of the Effective Date, and (ii) contains terms no less favorable
to ICANN than the Continued Operations Instrument and is otherwise in form andsubstance reasonably acceptable to ICANN. In the event Registry Operator replaces
the Continued Operations Instrument either pursuant to paragraph 2 or thisparagraph 3, the terms of this Specification 8 shall no longer apply with respect tothe original Continuing Operations Instrument, but shall thereafter apply withrespect to such Alternative Instrument(s), and such instrument shall thereafter beconsidered the Continued Operations Instrument for purposes of this Agreement.

86SPECIFICATION 9REGISTRY 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 otherrelated 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 registrysystems and related registry services, unless comparable opportunities toqualify 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 throughan ICANN accredited registrar; provided, however, that Registry Operator
may (a) reserve names from registration pursuant to Section 2.6 of theAgreement and (b) may withhold from registration or allocate to Registry
Operator up to one hundred (100) names pursuant to Section 3.2 ofSpecification 5;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”);
ord.

allow any Affiliated registrar to disclose Personal Data about registrants toRegistry 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 ofregistrar 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 ofregistrar 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 acertification executed by an executive officer of Registry Operator certifying as to87

Registry Operator’s compliance with this Code of Conduct, via email to an address tobe provided by ICANN. (ICANN may specify in the future the form and contents ofsuch reports or that the reports be delivered by other reasonable means.) Registry
Operator agrees that ICANN may publicly post such results and certification;
provided, however, ICANN shall not disclose Confidential Information contained insuch results except in accordance with Section 7.15 of the Agreement.
4.

Nothing set forth herein shall: (i) limit ICANN from conducting investigations ofclaims 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 ofbusiness 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 nameregistrations in the TLD are registered to, and maintained by, Registry Operator forthe 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 thisCode of Conduct to the TLD is not necessary to protect the public interest.

88

SPECIFICATION 10
REGISTRY PERFORMANCE SPECIFICATIONS
1.

2.

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 theroot trust anchor to a particular domain name, e.g., a TLD, a domain nameregistered 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 thisAgreement.

1.7.

RTT. Round-Trip Time or RTT refers to the time measured from the sendingof the first bit of the first packet of the sequence of packets needed to make arequest until the reception of the last bit of the last packet of the sequenceneeded 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).

Service Level Agreement Matrix
Parameter

DNS

RDDS

SLR (monthly basis)

DNS service availability
DNS name server availability
TCP DNS resolution RTT
UDP DNS resolution RTT
DNS update time
RDDS availability

0 min downtime = 100% availability 432 min of downtime ( 99%)
 1500 ms, for at least 95% of the queries
 500 ms, for at least 95% of the queries
 60 min, for at least 95% of the probes 864 min of downtime ( 98%)
89

EPP

RDDS query RTT
RDDS update time
EPP service availability
EPP session-command RTT
EPP query-command RTT
EPP transform-command RTT

 2000 ms, for at least 95% of the queries
 60 min, for at least 95% of the probes 864 min of downtime ( 98%)
 4000 ms, for at least 90% of the commands
 2000 ms, for at least 90% of the commands
 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 noprovision 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 oflisted-as-authoritative name servers of a particular domain name (e.g., aTLD), to answer DNS queries from DNS probes. For the service to beconsidered available at a particular moment, at least, two of the delegatedname servers registered in the DNS must have successful results from “DNS
tests” to each of their public-DNS registered “IP addresses” to which thename server resolves. If 51% or more of the DNS testing probes see theservice 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 fora 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 testingprobes get undefined/unanswered results from “DNS tests” to a name server“IP address” during a given time, the name server “IP address” will beconsidered 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 beconsidered 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 thetime 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”.
90

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 nameservers of the parent domain name answer “DNS queries” with dataconsistent 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, fora query to be considered answered, the signatures must be positively verified
against a corresponding DS record published in the parent zone or, if theparent is not signed, against a statically configured Trust Anchor. The
answer to the query must contain the corresponding information from theRegistry 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 beplaced as near as possible to the DNS resolvers on the networks with themost 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 therelevant Registry System. If 51% or more of the RDDS testing probes see anyof the RDDS services as unavailable during a given time, the RDDS will beconsidered unavailable.

91

4.2.

WHOIS query RTT. Refers to the RTT of the sequence of packets from thestart 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 thereception 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 thecorresponding 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 theservers 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 asunanswered. The possible results to an RDDS test are: a number inmilliseconds corresponding to the RTT or undefined/unanswered.

4.7.

Measuring RDDS parameters. Every 5 minutes, RDDS probes will selectone IP address from all the public-DNS registered “IP addresses” of theservers 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 thatprobe 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 shallbe placed inside the networks with the most users across the different
geographic regions; care shall be taken not to deploy probes behind highpropagation-delay links, such as satellite links.

92

5.

EPP
5.1.

EPP service availability. Refers to the ability of the TLD EPP servers as agroup, to respond to commands from the Registry accredited Registrars, whoalready 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 beconsidered 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 beconsidered 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 beconsidered 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 querycommands 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 receptionof the EPP response for only one EPP transform command. It does notinclude 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 oneof the EPP servers. Query and transform commands, with the exception of“create”, shall be about existing objects in the Registry System. The responseshall 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.

93

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 ofcommands 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 beplaced inside or close to Registrars points of access to the Internet across thedifferent geographic regions; care shall be taken not to deploy probes behindhigh propagation-delay links, such as satellite links.

Emergency Thresholds

6.

The following matrix presents the emergency thresholds that, if reached by any of theservices mentioned above for a TLD, would cause the emergency transition of the Registry
for the TLD as specified in Section 2.13 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 / weekRDDS

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 andRegistry Operator, and Registrars and ICANN. Registry Operators and ICANN must provide
said emergency operations departments. Current contacts must be maintained between
94

ICANN and Registry Operators and published to Registrars, where relevant to their role inescalations, prior to any processing of an Emergency Escalation by all related parties, andkept current at all times.
7.1.

Emergency Escalation initiated by ICANN

Upon reaching 10% of the Emergency thresholds as described in Section 6 of thisSpecification, ICANN’s emergency operations will initiate an Emergency Escalation with therelevant 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 theissue 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 isunable to either contact (through ICANN mandated methods of communication) the
Registry Operator, or the Registry Operator is unable or unwilling to address the fault, theregistrar 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 MaintenanceIn 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 thatmaintenance. ICANN’s emergency operations department will note planned maintenancetimes, 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 forthe 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 themonitored services. Registry Operator shall respond to the measurement95

tests described in this Specification as it would to any other request from anInternet user (for DNS and RDDS) or registrar (for EPP).
8.2.

ICANN testing registrar. Registry Operator agrees that ICANN will have atesting registrar used for purposes of measuring the SLRs described above.
Registry Operator agrees to not provide any differentiated treatment for thetesting 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 compliancewith the conditions described in this Agreement. Registry Operator shallidentify these transactions using Registrar ID 9997.

96

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 suchregistrars shall be maintained by ICANN on ICANN’s website.
2. Registry Operator will operate the registry for the TLD in compliance with allcommitments, statements of intent and business plans stated in the following
sections of Registry Operator’s application to ICANN for the TLD, which
commitments, statements of intent and business plans are hereby
incorporated by reference into this Agreement. Registry Operator’s
obligations pursuant to this paragraph shall be enforceable by ICANN andthrough the Public Interest Commitment Dispute Resolution Processestablished by ICANN (posted at
http://www.icann.org/en/resources/registries/picdrp), which may berevised in immaterial respects by ICANN from time to time (the “PICDRP”).
Registry Operator shall comply with the PICDRP. Registry Operator agrees toimplement and adhere to any remedies ICANN imposes (which may include
any reasonable remedy, including for the avoidance of doubt, the terminationof the Registry Agreement pursuant to Section 4.3(e) of the Agreement)
following a determination by any PICDRP panel and to be bound by any suchdetermination[Registry Operator to insert specific application sections here, if applicable]
3. Registry Operator agrees to perform the following specific public interest
commitments, which commitments shall be enforceable by ICANN andthrough the Public Interest Commitment Dispute Resolution Processestablished by ICANN (posted at
http://www.icann.org/en/resources/registries/picdrp), which may berevised in immaterial respects by ICANN from time to time (the “PICDRP”).
Registry Operator shall comply with the PICDRP. Registry Operator agrees toimplement and adhere to any remedies ICANN imposes (which may include
any reasonable remedy, including for the avoidance of doubt, the terminationof the Registry Agreement pursuant to Section 4.3(e) of the Agreement)
following a determination by any PICDRP panel and to be bound by any suchdetermination.
a. 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
97

practices, counterfeiting or otherwise engaging in activity contrary toapplicable law, and providing (consistent with applicable law and any
related procedures) consequences for such activities including
suspension of the domain name.
b. Registry Operator will periodically conduct a technical analysis toassess whether domains in the TLD are being used to perpetratesecurity 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 theperiodic security checks. Registry Operator will maintain thesereports for the term of the Agreement unless a shorter period isrequired by law or approved by ICANN, and will provide them to
ICANN upon request.
c. Registry Operator will operate the TLD in a transparent mannerconsistent with general principles of openness andnon-discrimination by establishing, publishing and adhering to clear
registration policies.
d. 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 2.9(c) of the Registry 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 brandof goods, services, groups, organizations or things from those ofothers.

98

SPECIFICATION 12
COMMUNITY REGISTRATION POLICIESRegistry Operator shall implement and comply with all community registration
policies described below and/or attached to this Specification 12.
[Insert registration policies]99