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 Jaguar
Land Rover Ltd, a corporation formed under the laws of the United Kingdom (“Registry
Operator”).

ARTICLE 1.

DELEGATION AND OPERATION
OF TOP–LEVEL DOMAIN; REPRESENTATIONS AND WARRANTIES

1.1Domain and Designation. The Top-Level Domain to which this Agreement applies
is .jaguar(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 the root-zone.

1.2Technical Feasibility of
String. While ICANN has
encouraged and will continue to encourage universal acceptance of all top-level
domain strings across the Internet, 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 to entering into
this Agreement.

1.3Representations and
Warranties.

(a)Registry Operator represents
and warrants to ICANN as follows:

(i)all material information
provided and statements made in the registry TLD application, and statements
made in writing during the negotiation of this Agreement, were true and correct
in all material respects at the time made, and such information or statements
continue to be true and correct 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 in good 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 binding obligation of the parties thereto, enforceable against the parties
thereto in accordance 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 and
duly execute and deliver this Agreement.

ARTICLE 2.

COVENANTS OF REGISTRY OPERATOR

Registry
Operator covenants and agrees with ICANN as follows:

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

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

2.4Monthly Reporting. Within twenty (20) calendar days following the
end of each calendar month, Registry Operator shall deliver to ICANN reports in
the format set forth in Specification 3 attached hereto (“Specification 3”).

2.6Reserved Names. Except to the extent that ICANN otherwise
expressly authorizes in writing, Registry Operator shall comply with the
requirements set forth in Specification 5 attached hereto (“Specification 5”).
Registry Operator may at any time establish or modify policies concerning
Registry Operator’s ability to reserve (i.e., withhold from registration or
allocate to Registry Operator, but not register to third parties, delegate,
use, activate in the DNS or otherwise make available) or block additional
character strings within the TLD at its discretion. Except as specified in
Specification 5, if Registry Operator is the registrant for any domain names in
the registry TLD, such registrations must be through an ICANN accredited
registrar, and will be considered Transactions (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.8Protection of Legal
Rights of Third Parties. Registry
Operator must specify, 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 or
modifications to the process and procedures required by Specification 7
following the Effective Date must be approved in advance by ICANN in writing.
Registry Operator must comply with all remedies imposed by ICANN pursuant to
Section 2 of Specification 7, subject to Registry Operator’s right to challenge
such remedies as set forth in the applicable procedure described therein.
Registry Operator shall take reasonable steps to investigate and respond to any
reports from law enforcement and governmental and quasi-governmental agencies
of illegal conduct in connection with the use of the TLD. In responding to
such reports, Registry Operator will not be required to take any action in
contravention of applicable law.

2.9Registrars.

(a)All domain name registrations
in the TLD must be registered through an 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 the proper 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 register names in the TLD at least fifteen (15) calendar days written notice
of any revisions to the Registry-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 this
Section 2.9(a), that such revisions are immaterial, then Registry Operator may
adopt and implement such revisions. If ICANN determines such revisions are
either material or potentially material, ICANN will thereafter follow its
procedure regarding review and approval 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.

(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 the contract, transaction or other arrangement that resulted in such
affiliation, reseller relationship or subcontract, as applicable, including, if
requested by ICANN, copies of any contract relating thereto; provided, that
ICANN will 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, related documents, transaction or other arrangement to relevant
competition authorities in the event that ICANN determines that such contract,
related documents, transaction or other 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 or entity 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 a person or entity, whether through the ownership of
securities, as trustee or executor, by serving as an employee or a member of a
board of directors or equivalent governing body, by contract, by credit
arrangement or otherwise.

2.10Pricing for Registry
Services.

(a)With respect to initial domain
name registrations, Registry Operator shall provide ICANN and each ICANN
accredited registrar that has executed the registry-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 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 clearly and 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 domain name 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 ICANN and each ICANN
accredited registrar that has executed the registry-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 price
charged to registrars) of no less than one hundred eighty (180) calendar days.
Notwithstanding the foregoing sentence, with respect to renewal of domain name
registrations: (i) Registry Operator need only provide thirty (30) calendar
days notice of any price increase if the resulting price is less than or equal
to (A) for the period beginning on 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 price increase; and (ii) Registry Operator need not
provide notice of any price increase for the imposition 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 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 renewals of domain name registrations (“Renewal
Pricing”). For the purposes of determining Renewal Pricing, the price for each
domain registration renewal must be identical to the price 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 agreement with registrar to higher Renewal
Pricing at the time of the initial registration of the domain name following
clear and conspicuous disclosure of such Renewal Pricing to such registrant,
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 to prohibit 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 a
marketing 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 of determining 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 particular class(es) of
registrations (e.g., registrations held by large corporations) or increase the
renewal 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).

(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. Such
audits 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 reasonable detail the categories of documents, data and other
information requested by ICANN, and (b) use commercially reasonable efforts to
conduct such audit during regular business hours 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 provide all
responsive documents, data and any other information reasonably necessary to
demonstrate Registry Operator’s compliance with this Agreement. Upon no less
than ten (10) calendar days notice (unless otherwise agreed to by Registry
Operator), ICANN may, as part of any contractual compliance audit, conduct site
visits during regular business hours to assess compliance by Registry Operator
with its representations and warranties contained in Article 1 of this
Agreement and its covenants contained in Article 2 of this Agreement. ICANN
will treat any information obtained in connection with such audits that is
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’s compliance 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 a discrepancy 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 such case of (i) or (ii) above, such reimbursement will be paid
together with the next Registry- Level Fee payment due following the date of
transmittal of the cost statement for such audit.

(c)Notwithstanding Section
2.11(a), if Registry Operator is found not to be in compliance with its
representations and warranties contained in Article 1 of this Agreement 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 such
audits to one per calendar quarter.

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

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

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

2.15Cooperation with
Economic Studies. If ICANN
initiates or commissions an economic study on the impact or functioning of new
generic top-level domains on the Internet, the DNS or related matters, Registry
Operator shall reasonably cooperate with such 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 data and (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 treated as 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.16Registry 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.

2.18Personal 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 for which data about any identified or identifiable
natural person (“Personal Data”) submitted to Registry Operator by such
registrar is collected and used under this Agreement or otherwise and the
intended recipients (or categories of recipients) of such Personal Data, and
(ii) require such registrar to obtain the consent of each registrant in the TLD
for such collection and use of Personal Data. Registry Operator shall take
reasonable steps to protect Personal Data collected from such registrar from
loss, misuse, unauthorized disclosure, alteration or destruction. Registry
Operator shall not use or authorize the use of Personal Data in a way that is
incompatible with the notice provided to registrars.

ARTICLE 3.

COVENANTS OF ICANN

ICANN
covenants and agrees with Registry Operator as follows:

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

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

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

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

3.5Authoritative 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 the authoritative 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 that any 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.1Term. 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.2Renewal.

(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 a fundamental and material breach of Registry Operator’s covenants
set forth in Article 2 or breach of its payment obligations under Article 6 of
this Agreement, which notice shall include with specificity the details of the
alleged breach, and such breach has not been cured within thirty (30) calendar
days of such notice, (A) an arbitrator or court of competent jurisdiction 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 with such determination and 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; or

(ii)During the then current Term,
Registry Operator shall have been 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 to have 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.3Termination by ICANN.

(a)ICANN may, upon notice to
Registry Operator, terminate this Agreement if: (i) Registry Operator
fails to cure (A) any fundamental and material breach of 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
forth in 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 the details of the alleged breach, (ii) an arbitrator
or court of competent jurisdiction has finally determined that Registry
Operator is in fundamental and material breach of such covenant(s) or in breach
of its payment obligations, and (iii) Registry Operator fails to comply with
such determination and 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.

(b)ICANN may, upon notice to
Registry Operator, terminate this Agreement 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 can
demonstrate, to ICANN’s reasonable satisfaction, that Registry Operator is
working diligently and in good faith toward successfully completing the steps
necessary for delegation of the TLD. Any fees paid by Registry Operator to
ICANN prior to such termination date shall be retained by ICANN in full.

(c)ICANN may, upon notice to Registry
Operator, terminate this Agreement 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 of
delivery 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 the Effective Date, (ii) an arbitrator or court of
competent jurisdiction has finally determined that 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.

(d)ICANN may, upon notice to Registry
Operator, terminate this Agreement if (i) Registry Operator makes an
assignment for the benefit of creditors or similar act, (ii) attachment,
garnishment or similar proceedings are commenced against Registry Operator,
which proceedings are a material threat to Registry Operator’s ability to
operate the registry for the TLD, and are not dismissed within sixty (60)
calendar days of their commencement, (iii) a trustee, receiver, liquidator or
equivalent is appointed in place of Registry Operator or maintains control over
any of Registry Operator’s property, (iv) execution is levied upon any material
property of Registry Operator, (v) proceedings are instituted by or against
Registry Operator under any bankruptcy, insolvency, reorganization or other
laws relating to the relief of debtors and such proceedings are not dismissed
within sixty (60) calendar days of their commencement, 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 Section 2 of Specification 7 or Sections 2 and 3 of Specification 11,
subject to Registry 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 this Agreement if (i) Registry Operator
knowingly employs any officer who is convicted of a misdemeanor related to
financial activities or of any felony, or is judged by a court of competent
jurisdiction to have committed fraud or breach of fiduciary duty, or is the
subject of a judicial determination that ICANN reasonably deems as the
substantive equivalent of any of the foregoing and such officer is not
terminated within thirty (30) calendar days of Registry Operator’s knowledge of
the foregoing, or (ii) any member of Registry Operator’s board of directors or
similar governing body is convicted of a misdemeanor related to financial
activities or of any felony, or is judged by a court of competent jurisdiction
to have committed fraud or breach of fiduciary duty, or is the subject of a
judicial determination that ICANN reasonably deems as the substantive
equivalent of any of the foregoing and such member is not removed from Registry
Operator’s board of directors or similar governing body within thirty (30)
calendar days of Registry Operator’s knowledge of the foregoing.

(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 to comply with such
determination and 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.

(b)Registry Operator may terminate
this Agreement for any reason upon one hundred eighty (180) calendar day
advance notice to ICANN.

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

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

ARTICLE 5.

DISPUTE RESOLUTION

5.1Mediation. In the event of any dispute arising under or in
connection with this 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 in accordance with the following terms
and conditions:

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

(b)The mediator shall conduct the
mediation in accordance with the rules and procedures that he or she determines
following consultation with the parties. The parties shall discuss the dispute
in good faith and attempt, with the mediator’s assistance, to reach an amicable
resolution of the dispute. The mediation shall be treated as a settlement
discussion and shall therefore be confidential and may not be used against
either party in any later proceeding relating to the dispute, including any
arbitration pursuant to Section 5.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 shall share equally the fees and expenses
of the mediator. Each party shall treat information received from the other
party pursuant to the mediation that is appropriately marked as confidential
(as required by Section 7.15) as Confidential Information of such other party
in accordance 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 by agreement of the parties) and the dispute can then proceed to
arbitration pursuant to Section 5.2 below.

5.2Arbitration. 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 arbitration will be conducted in
the English language and will occur in Los Angeles County, California. Any
arbitration will be in front of a single arbitrator, unless (i) ICANN is
seeking punitive or exemplary damages, or operational sanctions, (ii) the
parties agree in writing to a greater number of arbitrators, 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 with each party selecting one arbitrator and the two selected
arbitrators selecting the third arbitrator. In order to expedite the
arbitration and limit its cost, the arbitrator(s) shall establish page limits
for the parties’ filings in conjunction with the arbitration, and should the
arbitrator(s) determine that a hearing is necessary, the hearing shall be
limited to one (1) calendar day, provided that in any arbitration in which ICANN
is seeking punitive or exemplary damages, or operational sanctions, the hearing
may be extended for one (1) additional calendar day if agreed upon by the
parties or ordered by the arbitrator(s) based on the arbitrator(s) independent
determination or the reasonable request of one of the parties thereto. The
prevailing party in the arbitration will have the right to recover its costs
and reasonable attorneys’ fees, which the arbitrator(s) shall include in the
awards. In the event the arbitrators determine that Registry Operator has been
repeatedly and willfully in fundamental and material breach of its obligations
set forth in 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 such other 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 to enforce a
judgment of such a court in any court of competent jurisdiction.

5.3Limitation of Liability. ICANN’s aggregate monetary liability for
violations of 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 this Agreement (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, if any), 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, exemplary or
consequential damages arising out of or in connection with this Agreement or
the performance or nonperformance of obligations undertaken in this Agreement,
except as provided in Section 5.2. Except as otherwise provided in this
Agreement, neither party 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 particular purpose.

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

ARTICLE 6.

FEES

6.1Registry-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 transaction fee (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 (at one 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-level transaction fee shall not apply until
and unless more than 50,000 Transactions have occurred 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 Transaction
that occurred during each quarter in which the Transaction Threshold has been
met, but shall 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 the date 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 the
delegation date falls.

(b)Subject to Section 6.1(a),
Registry Operator shall pay the Registry-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.2Cost Recovery for RSTEP. Requests by Registry Operator for the approval
of 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, unless ICANN determines, in its sole and absolute
discretion, to pay all or any portion of the invoiced cost of such RSTEP
review.

6.3Variable Registry-Level
Fee.

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

(b)The amount of the Variable
Registry-Level Fee will be specified for each registrar, and may include both a
per-registrar component and a transactional component. 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.

6.4Pass 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 in Specification 7 (the “RPM Access Fee”) and (ii)
an amount specified by ICANN not to exceed 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 such fee 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.5Adjustments 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 to the 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 for the month which is one (1) month prior to the
commencement of the immediately prior year. 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 shall be 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.6Additional 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 by applicable law.

ARTICLE 7.

miscellaneous

7.1Indemnification of
ICANN.

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

(b)For any claims by ICANN for
indemnification whereby multiple registry operators (including Registry
Operator) have engaged in the same actions or omissions that gave rise to the
claim, Registry Operator’s aggregate liability to indemnify ICANN with respect
to such claim shall be limited to a percentage of ICANN’s total claim,
calculated by dividing the number of total domain names under registration with
Registry Operator within the TLD (which names under registration shall be
calculated consistently with Article 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 are 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 not have 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.

7.2Indemnification
Procedures. If any third-party
claim is commenced that is indemnified 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 and
investigation 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 the litigation 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 of such 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 of such claim and any appeal arising
therefrom. No settlement of a claim that involves a remedy affecting ICANN
other than the payment of money in an amount that is 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 such defense in accordance with this Section 7.2, ICANN will have
the right to defend the claim in such manner as it may deem appropriate, at the
cost and expense of Registry Operator and Registry Operator shall cooperate in
such defense.

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

(a)For 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 by systems
operating in accordance with all applicable standards.

(b)For purposes of this Agreement,
an effect on “Stability” shall refer to (1) lack of compliance with applicable
relevant standards that are authoritative and published by a well-established
and recognized Internet standards body, such as the relevant Standards-Track or
Best Current Practice Requests for Comments (“RFCs”) sponsored by the Internet
Engineering Task Force; or (2) the creation of a condition that adversely
affects the throughput, response time, consistency or coherence of responses to
Internet servers or end systems operating in accordance with applicable
relevant standards that are authoritative and published by a well-established
and recognized Internet 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.4No Offset. All payments due under this Agreement will be
made in a timely manner throughout the Term and notwithstanding the pendency of
any dispute (monetary or otherwise) between Registry Operator and ICANN.

7.5Change 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 this Agreement 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 of control of
Registry Operator or any subcontracting arrangement that relates to any
Critical Function (as identified in Section 6 of Specification 10) for the TLD
(a “Material Subcontracting Arrangement”) shall be deemed an assignment.

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

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

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

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

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

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

7.6Amendments and Waivers.

(a)If the ICANN Board of Directors
determines that an amendment to this Agreement (including to the Specifications
referred to herein) and all other registry agreements 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.

(b)Prior to submitting a Special
Amendment for Registry Operator Approval, ICANN shall first consult in good
faith with the Working Group regarding the form and substance of such Special
Amendment. The duration of such consultation shall be reasonably 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 public comments submitted on a Special Amendment during the
Posting Period (including comments 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 public comment, but must
address the subject matter of the Special Amendment posted for public comment,
as modified to reflect and/or address input from the Working Group and public
comments), 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, such Special Amendment shall be deemed approved (an
“Approved Amendment”) by the Applicable Registry Operators, and shall be
effective and deemed an amendment to this Agreement 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 of Specification 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 adoption of 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 Rejected Amendment for Registry
Operator Approval pursuant to Section 7.6(c), the subject matter of 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 of such Rejected
Amendment for Registry Operator Approval pursuant to Section 7.6(c), the
subject 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 and Compelling Reason in the Public Interest, must
be likely to promote such interest, taking into account competing public and
private interests that are likely 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 no less 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 to engage 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
no less than sixty (60) calendar days; and (b) following such consultation,
reapprove the Rejected Amendment (which may be in a form different than submitted
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 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 (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 the date that is sixty (60) calendar days
following the date ICANN provided notice of the approval of such Board
Amendment to Registry Operator (which effective date shall be deemed the
Amendment Effective Date hereunder). Notwithstanding the foregoing, a Board
Amendment may not amend the registry fees charged by ICANN hereunder, or amend
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, the Working 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 to amend 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
less restrictive 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 the Board
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 be deemed an Approved Amendment hereunder (and shall be effective and
deemed an amendment to this Agreement on the date that is sixty (60) calendar
days following the date 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 the affirmative
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 by such two-thirds
vote, the Board Amendment (and not the Alternative Amendment) shall be
effective 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 Board of 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 the criteria 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 a three-person arbitration panel. Any such challenge must
be brought within sixty (60) calendar days following the date ICANN provided
notice to Registry Operator of the Approved 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 of the 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 with 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 be conditioned 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 or variations of
the Approved Amendment required by ICANN shall be effective and, to the extent
applicable, will amend this Agreement as of the Amendment Effective Date. If
such Exemption Request is denied by ICANN, the Approved Amendment will amend
this Agreement 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 the dispute resolution procedures set forth
in Article 5. The Approved Amendment will be deemed not to have amended this
Agreement during the pendency of the dispute resolution process. For avoidance
of doubt, only Exemption Requests submitted by Registry 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 in writing
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 this Agreement negotiated solely between the two parties. No waiver of any
provision of this Agreement shall be binding unless evidenced by a writing
signed by the party waiving compliance with such provision. No waiver of any
of the provisions of this Agreement or failure to enforce any of the provisions
hereof shall be deemed or shall constitute a waiver of any other provision
hereof, nor shall any such waiver constitute a continuing waiver unless
otherwise expressly provided. 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 the following meanings:

(i)“Applicable Registry Operators”
means, collectively, the registry 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 the following: (A) the affirmative approval of
the Applicable Registry Operators whose payments to ICANN accounted for
two-thirds of the total amount of fees (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 the date 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 a majority of the Applicable Registry Operators at the
time such approval is obtained. For the avoidance of doubt, with respect to
clause (B), each Applicable 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 a balanced 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 to become
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).

7.7Negotiation 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 other person, 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 faith negotiations regarding
the form and substance of the proposed revisions to this Agreement, 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 a
resolution 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 is reached 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 Operators in
accordance with Section 7.9. ICANN and the Working Group will consider the
public comments submitted on the 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 (as defined in Section 7.6) 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.

(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
the terms 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 a position paper with respect thereto on ICANN’s
website.

(i)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 following receipt by the
CEO or Chair, as applicable, of the Mediation 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 with general knowledge of contract law, who has no
ongoing business relationship with either party and, to the extent necessary to
mediate the particular dispute, general knowledge of the domain name system.
Any mediator must confirm in writing that he or she is not, and will not become
during the term of the mediation, an employee, partner, executive officer,
director, or security holder of ICANN or an Applicable Registry Operator. If
such confirmation is not provided by the appointed mediator, then a replacement
mediator shall be appointed pursuant to this Section 7.7(d)(i).

(ii)The mediator shall conduct the
mediation in accordance with the rules and procedures for facilitative
mediation 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.

(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 shall post the mutually agreed Proposed Revisions
on its website for the Posting Period and provide notice to all Applicable
Registry Operators in accordance with Section 7.9. ICANN and the Working Group
will consider the public comments 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 be considered in future arbitration, if
invoked. Those issues are subject to the limitations set forth in Section
7.7(e)(ii) below.

(e)If, following mediation, ICANN
and the Working Group have not reached an agreement on the Proposed Revisions,
either the CEO or the Chair may provide the other person written notice (an
“Arbitration Notice”) requiring ICANN and the Applicable Registry Operators to
resolve the dispute through binding arbitration in accordance with the
arbitration provisions of Section 5.2, subject to the requirements and
limitations of this Section 7.7(e).

(i)If an Arbitration Notice is
sent, the mediator’s definition of issues, along with the Proposed Revisions
(be those from ICANN, the Working 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 the Working 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 and after 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, the arbitration shall be
conducted pursuant to Section 5.2.

(ii)No dispute regarding the
Proposed Revisions may be submitted 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 (but only to the extent such Proposed
Revisions seek to implement an RPM not contemplated by Sections 2.8 and
Specification 7); Exhibit A; and Specifications 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, the proposed 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 of the costs and benefits to the business interests of the Applicable
Registry Operators and ICANN (as applicable), and the public benefit sought to
be achieved by the Proposed Revisions as set forth in such amendment. If the
arbitrator panel concludes that either ICANN or the Working Group’s proposed
amendment relating to the Proposed Revisions meets the foregoing standard, such
amendment shall be effective and deemed an amendment to this 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 to become
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.8No Third-Party
Beneficiaries. This Agreement
will not be construed to create any obligation by either ICANN or Registry
Operator to any non-party to this Agreement, including any registrar or
registered name holder.

7.9General Notices. Except for notices pursuant to Sections 7.6 and
7.7, all notices to be given under or in relation to this Agreement will be
given either (i) in writing at the address of the appropriate party as set
forth below or (ii) via facsimile or electronic mail as provided below, unless
that party has given a notice of change of postal or email address, or
facsimile number, as provided in this Agreement. 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 notice required 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 be followed 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 when electronically 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 this Agreement.

7.10Entire Agreement. This Agreement (including those specifications
and documents 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 and supersedes all prior agreements, understandings,
negotiations and discussions, whether oral or written, between the parties on
that subject.

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

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

7.13Severability; 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 good 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 applicable laws and non-WHOIS related provisions of this Agreement.
Until such procedure is developed 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.14Court Orders. ICANN will respect any order from a court of
competent jurisdiction, including any orders from any jurisdiction where the
consent or non-objection of the government was a requirement for the delegation
of the TLD. Notwithstanding any other provision of this Agreement, ICANN’s
implementation of any such order will not be a breach of this Agreement

7.15Confidentiality

(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 other competent
proof to have been in the receiving party’s possession prior to disclosure by
the disclosing 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 published by 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 have been
independently developed by or for the receiving party without reference to the
disclosing 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 of competent 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 the
receiving 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 subject of such order or other applicable
law be held in confidence by such court or other third party recipient, unless
the receiving party is not permitted to provide such notice under such 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 performance of 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 written agreement or through
professional responsibility standards.

* * * * *

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

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

1.DNS Service – TLD Zone
Contents

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

1.1.Apex SOA record

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

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

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

2.Anti-Abuse

Registry
Operator may suspend, delete or otherwise make changes to domain names in
compliance with its anti-abuse policy.

3.Searchable Whois

Notwithstanding
anything else in this Agreement, Registry Operator must offer a searchable
Whois service compliant with the requirements described in Section 1.10 of
Specification 4 of this Agreement. Registry Operator must make available the
services only to authenticated users after they logged in by supplying proper
credentials (i.e., user name and password). Registry Operator must issue such
credentials exclusively to eligible users and institutions that supply
sufficient proof of their legitimate interest in this feature (e.g., law
enforcement agencies).

SPECIFICATION 1

CONSENSUS POLICIES AND TEMPORARY
POLICIES SPECIFICATION

1.Consensus
Policies.

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

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

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

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

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

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

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

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

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

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

1.3.4maintenance 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.1prescribe or limit the price of
Registry Services;

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

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

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

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

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

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

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

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

SPECIFICATION 2

DATA ESCROW REQUIREMENTS

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

PART
A – TECHNICAL SPECIFICATIONS

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

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

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

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

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

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

3.Escrow
Format Specification.

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3.{type} is
replaced by:

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

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

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

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

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

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

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

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

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

8.Verification
Procedure.

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

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

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

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

(5)If Part A,
Section 9, reference 1 of this Specification includes a verification process,
that will be applied at this step.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SPECIFICATION 3

FORMAT AND CONTENT FOR REGISTRY OPERATOR MONTHLY REPORTING

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

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

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

Field #

Field name

Description

01

registrar-name

Registrar’s
full corporate name as registered with IANA

02

iana-id

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

03

total-domains

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

04

total-nameservers

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

05

net-adds-1-yr

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

06

net-adds-2-yr

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

07

net-adds-3-yr

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

08

net-adds-4-yr

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

09

net-adds-5-yr

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

10

net-adds-6-yr

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

11

net-adds-7-yr

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

12

net-adds-8-yr

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

13

net-adds-9-yr

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

14

net-adds-10-yr

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

15

net-renews-1-yr

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

16

net-renews-2-yr

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

17

net-renews-3-yr

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

18

net-renews-4-yr

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

19

net-renews-5-yr

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

20

net-renews-6-yr

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

21

net-renews-7-yr

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

22

net-renews-8-yr

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

23

net-renews-9-yr

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

24

net-renews-10-yr

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

25

transfer-gaining-successful

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

26

transfer-gaining-nacked

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

27

transfer-losing-successful

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

28

transfer-losing-nacked

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

29

transfer-disputed-won

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

30

transfer-disputed-lost

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

31

transfer-disputed-nodecision

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

32

deleted-domains-grace

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

33

deleted-domains-nograce

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

34

restored-domains

domain
names restored from redemption period

35

restored-noreport

total
number of restored names for which the registrar failed to submit a restore
report

36

agp-exemption-requests

total
number of AGP (add grace period) exemption requests

37

agp-exemptions-granted

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

38

agp-exempted-domains

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

39

attempted-adds

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

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

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

Field #

Field Name

Description

01

operational-registrars

number
of operational registrars at the end of the reporting period

02

ramp-up-registrars

number
of registrars that have received a password for access to OT&E at the end
of the reporting period

03

pre-ramp-up-registrars

number
of registrars that have requested access, but have not yet entered the
ramp-up period at the end of the reporting period

04

zfa-passwords

number
of active zone file access passwords at the end of the reporting period

05

whois-43-queries

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

06

web-whois-queries

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

07

searchable-whois-queries

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

08

dns-udp-queries-received

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

09

dns-udp-queries-responded

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

10

dns-tcp-queries-received

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

11

dns-tcp-queries-responded

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

12

srs-dom-check

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

13

srs-dom-create

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

14

srs-dom-delete

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

15

srs-dom-info

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

16

srs-dom-renew

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

17

srs-dom-rgp-restore-report

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

18

srs-dom-rgp-restore-request

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

19

srs-dom-transfer-approve

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

20

srs-dom-transfer-cancel

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

21

srs-dom-transfer-query

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

22

srs-dom-transfer-reject

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

23

srs-dom-transfer-request

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

24

srs-dom-update

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

25

srs-host-check

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

26

srs-host-create

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

27

srs-host-delete

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

28

srs-host-info

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

29

srs-host-update

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

30

srs-cont-check

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

31

srs-cont-create

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

32

srs-cont-delete

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

33

srs-cont-info

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

34

srs-cont-transfer-approve

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

35

srs-cont-transfer-cancel

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

36

srs-cont-transfer-query

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

37

srs-cont-transfer-reject

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

38

srs-cont-transfer-request

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

39

srs-cont-update

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

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

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

SPECIFICATION 4

REGISTRATION DATA PUBLICATION SERVICES

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.Zone File
Access

2.1.Third-Party
Access

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

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

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

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

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

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

3.TTL must be
present as a decimal integer.

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

5.All domain
names must be in lower case.

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

7.All domain
names must be fully qualified.

8.No $ORIGIN
directives.

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

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

11.No $INCLUDE
directives.

12.No $TTL
directives.

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

14.No use of
comments.

15.No blank
lines.

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

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

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

2.1.5Use of Data by User. Registry Operator will permit
user to use the zone file for lawful purposes; provided that (a) user takes all
reasonable steps to protect against unauthorized access to and use and
disclosure of the data and (b) under no circumstances will Registry Operator be
required or permitted to allow user to use the data to, (i) allow, enable, or
otherwise support the transmission by email, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other than
user’s own existing customers, or (ii) enable high volume, automated,
electronic processes that send queries or data to the systems of Registry
Operator or any ICANN-accredited registrar.

2.1.6Term 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.7No 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.1Assistance. Registry Operator will co-operate
and provide reasonable assistance to ICANN and the CZDA Provider to facilitate
and maintain the efficient access of zone file data by permitted users as
contemplated under this Schedule.

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

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

3.Bulk
Registration Data Access to ICANN

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

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

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

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

SPECIFICATION 5

SCHEDULE OF RESERVED NAMES

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

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

2.Two-character
labels. All
two-character ASCII labels shall be withheld from registration 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 for registration to any person or
entity other than Registry Operator, provided that such 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 considered Transactions 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 at All Levels for use in connection with the operation of
the registry for the TLD: NIC. Registry Operator may activate WWW, RDDS and
WHOIS in the DNS, but must activate NIC in the DNS, as necessary for the
operation of the TLD. None of WWW, RDDS, WHOIS or NIC may be released or
registered to any person (other than Registry Operator) or third party. Upon
conclusion of Registry Operator’s designation as operator of the registry for
the TLD all such withheld or allocated names shall be transferred as specified
by ICANN. Registry Operator may self-allocate and renew such names without use
of an ICANN accredited registrar, which will not be considered Transactions for
purposes of Section 6.1 of the Agreement.

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 the operation or the
promotion of the TLD. Registry Operator must act as the Registered Name Holder
of such names as that term is defined in the then-current ICANN Registrar
Accreditation Agreement (RAA). These activations will be considered
Transactions for purposes of Section 6.1 of the Agreement. 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 with ICANN 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 clause setting out the terms of the
registration agreement between a registrar and a registered name holder). At
Registry Operator’s discretion and in compliance with all other terms of this
Agreement, 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 another person or entity at Registry
Operator’s discretion. Upon conclusion of Registry Operator’s designation as
operator of the registry for the TLD, all such names that remain withheld from
registration or allocated to Registry Operator shall be transferred as
specified by ICANN. Upon ICANN’s request, Registry Operator shall provide a
listing of all names withheld or allocated to Registry Operator pursuant to
Section 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.

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

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

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

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

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

SPECIFICATION 6

REGISTRY INTEROPERABILITY AND CONTINUITY SPECIFICATIONS

1.Standards
Compliance

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

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

1.3.DNSSEC. Registry Operator shall sign
its TLD zone files implementing Domain Name System Security Extensions
(“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033,
4034, 4035, 4509 and their successors, and follow the best practices described
in RFC 4641 and its successors. If Registry Operator implements Hashed Authenticated
Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155
and its successors. Registry Operator shall accept public-key material from
child domain names in a secure manner according to industry best practices.
Registry shall also publish in its website the DNSSEC Practice Statements (DPS)
describing critical security controls and procedures for key material storage,
access and usage for its own keys and secure acceptance of registrants’
public-key material. Registry Operator shall publish its DPS following the
format described in RFC 6841.

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

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

2.Registry
Services

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

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

3.Registry
Continuity

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

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

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

4.Abuse
Mitigation

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

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

5.Supported
Initial and Renewal Registration Periods

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

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

6.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 to activate names until the
No-Activation Period ends.

6.2.Name
Collision Occurrence Assessment

6.2.1Registry Operator shall not activate
any names in the DNS zone for the Registry TLD except in compliance with a Name
Collision Occurrence Assessment provided by ICANN regarding the Registry TLD.
Registry Operator will either (A) implement the mitigation measures described
in its Name Collision Occurrence Assessment before activating any second-level
domain name, or (B) block those second-level domain names for which the
mitigation measures as described in the Name Collision Occurrence Assessment
have not been implemented and proceed with activating names that are not listed
in the Assessment.

6.2.2Notwithstanding subsection 6.2.1,
Registry Operator may proceed with activation of names in the DNS zone without
implementation of the measures set forth in Section 6.2.1 only if (A) ICANN
determines that the Registry TLD is eligible for this alternative path to
activation of names; and (B) Registry Operator blocks all second-level domain
names identified by ICANN and set forth at
<http://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en>
as such list may be modified by ICANN from time to time. Registry Operator may
activate names pursuant to this subsection and later activate names pursuant to
subsection 6.2.1.

6.2.3The 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.4Registry Operator may participate
in the development by the ICANN community of a process for determining whether
and how these blocked names may be released.

6.2.5If ICANN determines that the TLD
is ineligible for the alternative path to 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 of names 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-new-gtld-annex-1-07oct13-en.pdf>.

6.3.Name
Collision Report Handling

6.3.1During the first two years after
delegation of the TLD, Registry Operator’s emergency operations department
shall be available to receive reports, relayed by ICANN, alleging demonstrably
severe harm from collisions with overlapping use of the names outside of the
authoritative DNS.

6.3.2Registry 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
and appropriate, remove a recently activated name from the TLD zone for a
period of up to two years in order to allow the affected party to make changes
to its systems.

SPECIFICATION 7

MINIMUM 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 this
Specification 7 and any additional RPMs developed and implemented by Registry
Operator in the registry-registrar agreement entered into by ICANN-accredited
registrars authorized to register names in the TLD. 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 instead of 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.

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

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

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 form of either (i) an irrevocable standby
letter of credit, or (ii) an irrevocable cash escrow deposit, each meeting 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 (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 the
Continued 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 with a one-year term and an “evergreen provision,” providing for
annual extensions, without amendment, for an indefinite number of additional
periods until the issuing bank 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 of any 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 of
credit. 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).

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
shall promptly (i) notify ICANN of such expiration or termination and the
reasons therefor and (ii) arrange for an alternative instrument that provides
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 (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 shall otherwise
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 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 one (1)
year following any termination of this Agreement after the fifth anniversary of
the Effective Date but prior to or on the sixth (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 and substance reasonably
acceptable to ICANN. In the event Registry Operator replaces the Continued
Operations Instrument either pursuant to paragraph 2 or this paragraph 3, the
terms of this Specification 8 shall no longer apply with respect to the
original Continuing Operations Instrument, but shall thereafter apply with
respect to such Alternative Instrument(s), and such instrument shall thereafter
be considered the Continued Operations Instrument for purposes of this
Agreement.

SPECIFICATION 9

Registry Operator Code of Conduct

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

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

b.register
domain names in its own right, except for names registered through an ICANN
accredited registrar; provided, however, that Registry Operator may (a) reserve
names from registration pursuant to Section 2.6 of the Agreement and (b) may
withhold from registration or allocate to Registry Operator up to one hundred
(100) names pursuant to Section 3.2 of Specification 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”); or

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

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

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

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

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

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

SPECIFICATION 10

REGISTRY PERFORMANCE SPECIFICATIONS

1.Definitions

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

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

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

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

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

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

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

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

2.Service
Level Agreement Matrix

Parameter

SLR (monthly basis)

DNS

DNS service
availability

0 min downtime = 100%
availability

DNS
name server availability

£ 432 min of downtime (» 99%)

TCP DNS
resolution RTT

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

UDP DNS
resolution RTT

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

DNS update
time

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

RDDS

RDDS
availability

£ 864 min of downtime (» 98%)

RDDS
query RTT

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

RDDS
update time

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

EPP

EPP
service availability

£ 864 min of downtime (» 98%)

EPP
session-command RTT

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

EPP
query-command RTT

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

EPP
transform-command RTT

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

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

3.DNS

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

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

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

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

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

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

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

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

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

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

4.RDDS

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

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

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

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

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

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

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

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

5.EPP

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

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

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

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

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

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

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

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

6.Emergency
Thresholds

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

Critical Function

Emergency Threshold

DNS
Service (all servers)

4-hour
total downtime / week

DNSSEC
proper resolution

4-hour
total downtime / week

EPP

24-hour
total downtime / week

RDDS
(WHOIS/Web-based WHOIS)

24-hour
total downtime / week

Data
Escrow

Breach
of the Registry Agreement as described in Specification 2, Part B, Section 6.

7.Emergency
Escalation

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

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

7.1.Emergency
Escalation initiated by ICANN

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

7.2.Emergency
Escalation initiated by Registrars

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

7.3.Notifications
of Outages and Maintenance

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

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

8.Covenants
of Performance Measurement

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

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

SPECIFICATION 11

PUBLIC INTEREST COMMITMENTS

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

2.(Intentionally
omitted. Registry Operator has not included commitments, statements of intent
or business plans provided for in its application to ICANN for the TLD.)

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

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 practices, counterfeiting or otherwise engaging in
activity contrary to applicable law, and providing (consistent with applicable
law and any related procedures) consequences for such activities including
suspension of the domain name.

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

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

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 brand
of goods, services, groups, organizations or things from those of others.