REGISTRY AGREEMENT
This
REGISTRY AGREEMENT (this “Agreement”) is entered into as of _________________
(the “Effective Date”) between Internet Corporation for Assigned Names and
Numbers, a California nonprofit public benefit corporation (“ICANN”), and Brice
Trail, LLC, a Delaware limited liability company (“Registry Operator”).
ARTICLE 1.
DELEGATION AND OPERATION
OF TOP–LEVEL DOMAIN; REPRESENTATIONS AND WARRANTIES
1.1
Domain and Designation.
The Top-Level Domain to which this Agreement applies is .doctor (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.2
Technical 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.3
Representations 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.1
Approved 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.2
Compliance with Consensus
Policies and Temporary Policies. Registry Operator shall
comply with and implement all Consensus Policies and Temporary Policies found
at <http://www.icann.org/general/consensus-policies.htm>, as of the
Effective 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.3
Data Escrow.
Registry Operator shall comply with the registry data escrow procedures
set forth in Specification 2 attached hereto (“Specification 2”).
2.4
Monthly 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.5
Publication of Registration Data.
Registry Operator shall provide public access to registration data in
accordance with Specification 4 attached hereto (“Specification 4”).
2.6
Reserved Names.
Except to the extent that ICANN otherwise expressly authorizes in
writing, Registry Operator shall comply with the requirements set forth 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.7
Registry Interoperability and
Continuity. Registry Operator shall comply with the
Registry Interoperability and Continuity Specifications as set forth in
Specification 6 attached hereto (“Specification 6”).
2.8
Protection of Legal Rights of
Third Parties. Registry Operator 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.9
Registrars.
(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.10
Pricing 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).
(d)
Registry Operator shall provide public query-based DNS lookup
service for the TLD (that is, operate the Registry TLD zone servers) at its
sole expense.
2.11
Contractual and Operational
Compliance Audits.
(a)
ICANN may from time to time (not to exceed twice per calendar
year) conduct, or engage a third party to conduct, contractual compliance
audits to assess compliance by Registry Operator with its representations and
warranties contained in Article 1 of this Agreement and its covenants contained
in Article 2 of this Agreement. 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.12
Continued Operations Instrument.
Registry Operator shall comply with the terms and conditions relating to
the Continued Operations Instrument set forth in Specification 8 attached
hereto (“Specification 8”).
2.13
Emergency Transition.
Registry Operator agrees that, in the event that any of the emergency
thresholds for registry functions set forth in Section 6 of Specification 10 is
reached, ICANN may designate an emergency interim registry operator of the
registry for the TLD (an “Emergency Operator”) in accordance with ICANN’s registry
transition process (available at
<http://www.icann.org/en/resources/registries/transition-processes>) (as
the same may be amended from time to time, the “Registry Transition Process”)
until such time as Registry Operator has demonstrated to ICANN’s reasonable
satisfaction that it can resume operation of the registry for the TLD without
the reoccurrence of such failure.
Following such demonstration, Registry Operator may transition back into
operation of the registry for the TLD pursuant to the procedures set out in the
Registry Transition Process, provided that Registry Operator pays all
reasonable costs incurred (i) by ICANN as a result of the designation of the
Emergency Operator and (ii) by the Emergency Operator in connection with the
operation of the registry for the TLD, which costs shall be documented in
reasonable detail in records that shall be made available to Registry
Operator. In the event ICANN designates
an Emergency Operator pursuant to this Section 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.14
Registry Code of Conduct.
In connection with the operation of the registry for the TLD, Registry
Operator shall comply with the Registry Code of Conduct as set forth in
Specification 9 attached hereto (“Specification 9”).
2.15
Cooperation with Economic Studies.
If ICANN initiates or commissions an economic study on the impact or
functioning of new generic top-level domains on 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.16
Registry Performance
Specifications. Registry Performance Specifications for
operation of the TLD will be as set forth in Specification 10 attached hereto
(“Specification 10”). Registry Operator
shall comply with such Performance Specifications and, for a period of at least
one (1) year, shall keep technical and operational records sufficient to
evidence compliance with such specifications for each calendar year during the
Term.
2.17
Additional Public Interest
Commitments. Registry Operator shall comply with the
public interest commitments set forth in Specification 11 attached hereto
(“Specification 11”).
2.18
Personal Data.
Registry Operator shall (i) notify each ICANN-accredited registrar that
is a party to the registry-registrar agreement for the TLD of the purposes 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.1
Open and Transparent. Consistent with ICANN’s
expressed mission and core values, ICANN shall operate in an open and
transparent manner.
3.2
Equitable Treatment.
ICANN shall not apply standards, policies, procedures or practices
arbitrarily, unjustifiably, or inequitably and shall not single out Registry
Operator for disparate treatment unless justified by substantial and reasonable
cause.
3.3
TLD Nameservers.
ICANN will use commercially reasonable efforts to ensure that any
changes to the TLD nameserver designations submitted to ICANN by Registry
Operator (in a format and with required technical elements specified by ICANN
at http://www.iana.org/domains/root/ will be implemented by ICANN within seven
(7) calendar days or as promptly as feasible following technical verifications.
3.4
Root-zone Information
Publication. ICANN’s publication of root-zone contact
information for the TLD will include Registry Operator and its administrative
and technical contacts. Any request to
modify the contact information for the Registry Operator must be made in the
format specified from time to time by ICANN at
http://www.iana.org/domains/root/.
3.5
Authoritative Root Database.
To the extent that ICANN is authorized to set policy with regard to an
authoritative root server system (the “Authoritative Root Server System”),
ICANN shall use commercially reasonable efforts to (a) ensure that 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.1
Term.
The term of this Agreement will be ten (10) years from the Effective
Date (as such term may be extended pursuant to Section 4.2, the “Term”).
4.2
Renewal.
(a)
This Agreement will be renewed for successive periods of ten (10)
years upon the expiration of the initial Term set forth in Section 4.1 and each
successive Term, unless:
(i)
Following notice by ICANN to Registry Operator of 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.3
Termination 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.
(g)
ICANN may, upon thirty (30) calendar days’ notice to Registry
Operator, terminate this Agreement as specified in Section 7.5.
4.4
Termination by Registry Operator.
(a)
Registry Operator may terminate this Agreement upon notice to
ICANN if (i) ICANN fails to cure any fundamental and material breach of
ICANN’s covenants set forth in Article 3, within thirty (30) calendar days
after Registry Operator gives ICANN notice of such breach, which notice will
include with specificity the details of the alleged breach, (ii) an arbitrator
or court of competent jurisdiction has finally determined that ICANN is in
fundamental and material breach of such covenants, and (iii) ICANN fails 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.5
Transition of Registry upon
Termination of Agreement. Upon expiration of the
Term pursuant to Section 4.1 or Section 4.2 or any termination of this
Agreement pursuant to Section 4.3 or Section 4.4, 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.6
Effect of Termination.
Upon any expiration of the Term or termination of this Agreement, the
obligations and rights of the parties hereto shall cease, provided that such
expiration or termination of this Agreement shall not relieve the parties of
any obligation or breach of this Agreement accruing prior to such expiration or
termination, including, without limitation, all accrued payment obligations
arising under 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.1
Mediation.
In the event of any dispute arising under or in connection with this
Agreement, before either party may initiate arbitration pursuant to Section 5.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.2
Arbitration.
Disputes arising under or in connection with this Agreement that are not
resolved pursuant to Section 5.1, including requests for specific performance,
will be resolved through binding arbitration conducted pursuant to the rules of
the International Court of Arbitration of the International Chamber of
Commerce. The 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.3
Limitation 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.4
Specific Performance.
Registry Operator and ICANN agree that irreparable damage could occur if
any of the provisions of this Agreement was not performed in accordance with
its specific terms. Accordingly, the
parties agree that they each shall be entitled to seek from the 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.1
Registry-Level Fees.
(a)
Registry Operator shall pay ICANN a registry-level fee equal to
(i) the registry fixed fee of US$6,250 per calendar quarter and (ii) the
registry-level 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.2
Cost 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.3
Variable 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.4
Pass Through Fees. Registry Operator shall pay
to ICANN (i) a one-time fee equal to US$5,000 for access to and use of the
Trademark Clearinghouse as described 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.5
Adjustments to Fees. Notwithstanding any of the fee limitations set forth in this
Article 6, commencing upon the expiration of the first year of this Agreement,
and upon the expiration of each year thereafter during the Term, the
then-current fees set forth in Section 6.1 and Section 6.3 may be adjusted, at
ICANN’s discretion, by a percentage equal 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.6
Additional Fee on Late Payments.
For any payments thirty (30) calendar days or more overdue under this
Agreement, Registry Operator shall pay an additional fee on late payments at
the rate of 1.5% per month or, if less, the maximum rate permitted by
applicable law.
ARTICLE 7.
miscellaneous
7.1
Indemnification of ICANN.
(a)
Registry Operator shall indemnify and defend ICANN and its
directors, officers, employees, and agents (collectively, “Indemnitees”) from
and against any and all third-party claims, damages, liabilities, costs, and
expenses, including reasonable legal fees and expenses, arising out of or
relating to intellectual property ownership rights with respect to the TLD, the
delegation of the TLD to Registry Operator, Registry Operator’s operation of
the registry for the TLD or Registry Operator’s provision of 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.2
Indemnification 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.3
Defined Terms.
For purposes of this Agreement, unless such definitions are amended
pursuant to a Consensus Policy at a future date, in which case the following
definitions shall be deemed amended and restated in their entirety as set forth
in such Consensus Policy, Security and Stability shall be defined as follows:
(a)
For 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.4
No Offset.
All payments due under this Agreement will be made in a timely manner
throughout the Term and notwithstanding the pendency of any dispute (monetary
or otherwise) between Registry Operator and ICANN.
7.5
Change of Control; Assignment and
Subcontracting. Except as set forth in this Section 7.5,
neither party may assign any of its rights and obligations under 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.6
Amendments 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.7
Negotiation Process.
(a)
If either the Chief Executive Officer of ICANN (“CEO”) or the
Chairperson of the Registry Stakeholder Group (“Chair”) desires to discuss any
revision(s) to this Agreement, the CEO or Chair, as applicable, shall provide
written notice to the 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.8
No 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.9
General 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.
If to ICANN, addressed to:
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
USA
Telephone: +1-310-301-5800
Facsimile: +1-310-823-8649
Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
If to Registry Operator, addressed to:
Brice Trail, LLC
10500 NE 8th Street,
Suite 350
Bellevue,
Washington 98004
Telephone: +1-424-254-8537
Fax: +1-425-671-0020
Attention:
Jonathon Nevett
Donuts Inc. Co-Founder and EVP
Email: jon@donuts.co
7.10
Entire 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.11
English 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.12
Ownership Rights.
Nothing contained in this Agreement shall be construed as (a)
establishing or granting to Registry Operator any property ownership rights or interests
of Registry Operator in the TLD or the letters, words, symbols or other
characters making up the TLD string, or (b) affecting any existing intellectual
property or ownership rights of Registry Operator.
7.13
Severability; Conflicts with Laws.
This Agreement shall be deemed severable; the invalidity or
unenforceability of any term or provision of this Agreement shall not affect
the validity or enforceability of the balance of this Agreement or of any other
term hereof, which shall remain in full force and effect. If any of the provisions hereof are
determined to be invalid or unenforceable, the parties shall negotiate in 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.14
Court Orders.
ICANN will respect any order from a court of competent jurisdiction,
including any orders from any jurisdiction where the consent or non-objection
of the government was a requirement for the delegation of the TLD. Notwithstanding any other provision of this
Agreement, ICANN’s implementation of any such order will not be a breach of
this Agreement
7.15
Confidentiality
(a)
Subject to Section 7.15(c), during the Term and for a period of
three (3) years thereafter, each party shall, and shall cause its and its
Affiliates’ officers, directors, employees and agents to, keep confidential and
not publish or otherwise disclose to any third party, directly or indirectly,
any information that is, and the disclosing party has marked as, or has
otherwise designated in writing to the receiving party as, “confidential trade
secret,” “confidential commercial information” or “confidential financial
information” (collectively, “Confidential Information”), except to the extent
such disclosure is permitted by the terms of this Agreement.
(b)
The confidentiality obligations under Section 7.15(a) shall not
apply to any Confidential Information that (i) is or hereafter becomes part of
the public domain by public use, publication, general knowledge or the like
through no fault of the receiving party in breach of this Agreement, (ii) can
be demonstrated by documentation or 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.
INTERNET CORPORATION FOR ASSIGNED NAMES AND
NUMBERS
By: _____________________________
Akram Atallah
President, Global Domains
Division
BRICE TRAIL, LLC
By: _____________________________
Paul Stahura
Manager of its Sole Member
EXHIBIT
A
Approved Services
The ICANN
gTLD Applicant Guidebook (located at
http://newgtlds.icann.org/en/applicants/agb) and the RSEP specify processes for
consideration of proposed registry services.
Registry Operator may provide any service that is required by the terms
of this Agreement. In addition, the
following services (if any) are specifically identified as having been approved
by ICANN prior to the effective date of the Agreement, and Registry Operator
may provide such services:
1.
DNS
Service – TLD Zone Contents
Notwithstanding
anything else in this Agreement, as indicated in section 2.2.3.3 of the gTLD
Applicant Guidebook, permissible contents for the TLD’s 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
1.4. DS records for registered names in
the TLD
1.5. Records associated with signing the
TLD zone (i.e., RRSIG, DNSKEY, NSEC, and NSEC3)
(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.
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).
3.
Internationalized
Domain Names (IDNs)
Registry
Operator may offer registration of IDNs at the second and lower levels provided
that Registry Operator complies with the following requirements:
3.1. Registry Operator must offer
Registrars support for handling IDN registrations in EPP.
3.2. Registry Operator must handle
variant IDNs as follows:
3.2.1.
Variant IDNs (as defined in the Registry Operator’s
IDN tables and IDN Registration Rules) will be blocked from registration.
3.3. Registry Operator may offer
registration of IDNs in the following languages/scripts (IDN Tables and IDN
Registration Rules will be published by the Registry Operator as specified in
the ICANN IDN Implementation Guidelines):
3.3.1.
French Language
3.3.2.
Spanish Language
4.
Specification
11 Registry Services
The following are descriptions of
the Registry Services listed in Specification 11:
4.1. Domains Protected Marks List (DPML)
The
DPML is a service that allows trademark rights holders to block certain labels
from registration across multiple TLDs operated by the Registry Operator. The
blocked names must comply with the provisions described in Specification 5,
Section 3.3 of the Registry Agreement. Domain Names blocked by the DPML service
will be either an exact match of a label or will contain an exact match of such
labels, or may include domain names that are a misspelling or contain a
misspelling of a label. Blocked labels do not prevent other trademark rights
holders from unblocking the label and registering the domain name.
4.2. Claims Plus
Claims Plus is a service that provides notice to Registrars that a domain name they are trying to
register matches a trademark registered in a trademark database used by the
Registry Operator.
SPECIFICATION 1
CONSENSUS
POLICIES AND TEMPORARY POLICIES SPECIFICATION
1.
Consensus Policies.
1.1.
“Consensus
Policies” are those policies established (1) pursuant to the procedure
set forth in ICANN’s Bylaws and due process, and (2) covering those topics
listed in Section 1.2 of this Specification. The Consensus Policy development process and
procedure set forth in ICANN’s Bylaws may be revised from time to time in
accordance with the process set forth therein.
1.2.
Consensus
Policies and the procedures by which they are developed shall be designed to
produce, to the extent possible, a consensus of Internet stakeholders,
including the operators of gTLDs.
Consensus Policies shall relate to one or more of the following:
1.2.1
issues for
which uniform or coordinated resolution is reasonably necessary to facilitate
interoperability, security and/or stability of the Internet or Domain Name
System (“DNS”);
1.2.2
functional
and performance specifications for the provision of Registry Services;
1.2.3
Security and
Stability of the registry database for the TLD;
1.2.4
registry
policies reasonably necessary to implement Consensus Policies relating to
registry operations or registrars;
1.2.5
resolution
of disputes regarding the registration of domain names (as opposed to the use
of such domain names); or
1.2.6
restrictions
on cross-ownership of registry operators and registrars or registrar resellers
and regulations and restrictions with respect to registry operations and the
use of registry and registrar data in the event that a registry operator and a
registrar or registrar reseller are affiliated.
1.3.
Such
categories of issues referred to in Section 1.2 of this Specification shall
include, without limitation:
1.3.1
principles
for allocation of registered names in the TLD (e.g., first-come/first-served,
timely renewal, holding period after expiration);
1.3.2
prohibitions
on warehousing of or speculation in domain names by registries or registrars;
1.3.3
reservation
of registered names in the TLD that may not be registered initially or that may
not be renewed due to reasons reasonably related to (i) avoidance of confusion
among or misleading of users, (ii) intellectual property, or (iii) the
technical management of the DNS or the Internet (e.g., establishment of
reservations of names from registration); and
1.3.4
maintenance
of and access to accurate and up-to-date information concerning domain name
registrations; and procedures to avoid disruptions of domain name registrations
due to suspension or termination of operations by a registry operator or a
registrar, including procedures for allocation of responsibility for serving
registered domain names in a TLD affected by such a suspension or termination.
1.4.
In addition
to the other limitations on Consensus Policies, they shall not:
1.4.1
prescribe or
limit the price of Registry Services;
1.4.2
modify the
terms or conditions for the renewal or termination of the Registry Agreement;
1.4.3
modify the
limitations on Temporary Policies (defined below) or Consensus Policies;
1.4.4
modify the
provisions in the registry agreement regarding fees paid by Registry Operator
to ICANN; or
1.4.5
modify
ICANN’s obligations to ensure equitable treatment of registry operators and act
in an open and transparent manner.
2.
Temporary Policies.
Registry Operator shall comply with and implement all specifications or
policies established by the Board on a temporary basis, if adopted by the Board
by a vote of at least two-thirds of its members, so long as the Board
reasonably determines that such modifications or amendments are justified and
that immediate temporary establishment of a specification or policy on the
subject is necessary to maintain the stability or security of Registry Services
or the DNS (“Temporary Policies”).
2.1.
Such
proposed specification or policy shall be as narrowly tailored as feasible to
achieve those objectives. In
establishing any Temporary Policy, the Board shall state the period of time for
which the Temporary Policy is adopted and shall immediately implement the
Consensus Policy development process set forth in ICANN’s Bylaws.
2.1.1
ICANN shall
also issue an advisory statement containing a detailed explanation of its
reasons for adopting the Temporary Policy and why the Board believes such
Temporary Policy should receive the consensus support of Internet stakeholders.
2.1.2
If the
period of time for which the Temporary Policy is adopted exceeds ninety (90)
calendar days, the Board shall reaffirm its temporary adoption every ninety
(90) calendar days for a total period not to exceed one (1) year, in order to
maintain such Temporary Policy in effect until such time as it becomes a
Consensus Policy. If the one (1) year
period expires or, if during such one (1) year period, the Temporary Policy
does not become a Consensus Policy and is not reaffirmed by the Board, Registry
Operator shall no longer be required to comply with or implement such Temporary
Policy.
3.
Notice and Conflicts.
Registry Operator shall be afforded a reasonable period of time
following notice of the establishment of a Consensus Policy or Temporary Policy
in which to comply with such policy or specification, taking into account any
urgency involved. In the event of a
conflict between Registry Services and Consensus Policies or any Temporary
Policy, the Consensus Polices or Temporary Policy shall control, but only with
respect to subject matter in conflict.
SPECIFICATION 2
DATA ESCROW REQUIREMENTS
Registry
Operator will engage an independent entity to act as data escrow agent (“Escrow
Agent”) for the provision of data escrow services related to the Registry
Agreement. The following Technical
Specifications set forth in Part A, and Legal Requirements set forth in Part B,
will be included in any data escrow agreement between Registry Operator and the
Escrow Agent, under which ICANN must be named a third-party beneficiary. In addition to the following requirements,
the data escrow agreement may contain other provisions that are not
contradictory or intended to subvert the required terms provided below.
PART A – TECHNICAL SPECIFICATIONS
1.
Deposits.
There will be two types of Deposits:
Full and Differential. For both
types, the universe of Registry objects to be considered for data escrow are
those objects necessary in order to offer all of the approved Registry
Services.
1.1.
“Full Deposit” will consist of data that
reflects the state of the registry as of 00:00:00 UTC (Coordinated Universal
Time) on the day that such Full Deposit is submitted to Escrow Agent.
1.2.
“Differential Deposit” means data that
reflects all transactions that were not reflected in the last previous Full or
Differential Deposit, as the case may be.
Each Differential Deposit will contain all database transactions since
the previous Deposit was completed as of 00:00:00 UTC of each day, but Sunday. Differential Deposits must include complete Escrow
Records as specified below that were not included or changed since the most
recent full or Differential Deposit (i.e., 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.
9.
References.
(1)
Domain Name
Data Escrow Specification (work in progress),
http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow
(2)
Domain Name
Registration Data (DNRD) Objects Mapping,
http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping
(3)
OpenPGP
Message Format, http://www.rfc-editor.org/rfc/rfc4880.txt
(4)
OpenPGP
parameters, http://www.iana.org/assignments/pgp‑parameters/pgp‑parameters.xhtml
(5)
ICANN
interfaces for registries and data escrow agents,
http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces
PART B – LEGAL REQUIREMENTS
1.
Escrow Agent.
Prior to entering into an escrow agreement, the Registry Operator must
provide notice to ICANN as to the identity of the Escrow Agent, and provide
ICANN with contact information and a copy of the relevant escrow agreement, and
all amendments thereto. In addition,
prior to entering into an escrow agreement, Registry Operator must obtain the
consent of ICANN to (a) use the specified Escrow Agent, and (b) enter into the
form of escrow agreement provided. ICANN
must be expressly designated as a third-party beneficiary of the escrow
agreement. ICANN reserves the right to
withhold its consent to any Escrow Agent, escrow agreement, or any amendment
thereto, all in its sole discretion.
2.
Fees. Registry Operator must
pay, or have paid on its behalf, fees to the Escrow Agent directly. If Registry Operator fails to pay any fee by
the due date(s), the Escrow Agent will give ICANN written notice of such
non-payment and ICANN may pay the past-due fee(s) within fifteen (15) calendar
days after receipt of the written notice from Escrow Agent. Upon payment of the past-due fees by ICANN,
ICANN shall have a claim for such amount against Registry Operator, which
Registry Operator shall be required to submit to ICANN together with the next
fee payment due under the Registry Agreement.
3.
Ownership.
Ownership of the Deposits during the effective term of the Registry
Agreement shall remain with Registry Operator at all times. Thereafter, Registry Operator shall assign
any such ownership rights (including intellectual property rights, as the case
may be) in such Deposits to ICANN. In
the event that during the term of the Registry Agreement any Deposit is
released from escrow to ICANN, any intellectual property rights held by Registry
Operator in the Deposits will automatically be licensed to ICANN or to a party
designated in writing by ICANN on a non-exclusive, perpetual, irrevocable,
royalty-free, paid-up basis, for any use related to the operation, maintenance
or transition of the TLD.
4.
Integrity and Confidentiality.
Escrow Agent will be required to (i) hold and maintain the Deposits in a
secure, locked, and environmentally safe facility, which is accessible only to
authorized representatives of Escrow Agent, (ii) protect the integrity and
confidentiality of the Deposits using commercially reasonable measures and
(iii) keep and safeguard each Deposit for one (1) year. ICANN and Registry Operator will be provided
the right to inspect Escrow Agent’s applicable records upon reasonable prior
notice and during normal business hours.
Registry Operator and ICANN will be provided with the right to designate
a third-party auditor to audit Escrow Agent’s compliance with the technical
specifications and maintenance requirements of this Specification 2 from time
to time.
If Escrow Agent receives a subpoena or any
other order from a court or other judicial tribunal pertaining to the
disclosure or release of the Deposits, Escrow Agent will promptly notify the
Registry Operator and ICANN unless prohibited by law. After notifying the Registry Operator and
ICANN, Escrow Agent shall allow sufficient time for Registry Operator or ICANN
to challenge any such order, which shall be the responsibility of Registry
Operator or ICANN; provided, however, that Escrow Agent does not waive its rights
to present its position with respect to any such order. Escrow Agent will cooperate with the Registry
Operator or ICANN to support efforts to quash or limit any subpoena, at such
party’s expense. Any party requesting
additional assistance shall pay Escrow Agent’s standard charges or as quoted
upon submission of a detailed request.
5.
Copies. Escrow Agent may be
permitted to duplicate any Deposit, in order to comply with the terms and
provisions of the escrow agreement.
6.
Release of Deposits.
Escrow Agent will make available for electronic download (unless
otherwise requested) to ICANN or its designee, within twenty-four (24) hours,
at the Registry Operator’s expense, all Deposits in Escrow Agent’s possession
in the event that the Escrow Agent receives a request from Registry Operator to
effect such delivery to ICANN, or receives one of the following written notices
by ICANN stating that:
6.1.
the Registry
Agreement has expired without renewal, or been terminated; or
6.2.
ICANN has
not received a notification as described in Part B, Sections 7.1 and 7.2 of
this Specification from Escrow Agent within five (5) calendar days after the
Deposit’s scheduled delivery date; (a) ICANN gave notice to Escrow Agent and
Registry Operator of that failure; and (b) ICANN has not, within seven (7)
calendar days after such notice, received the notification from Escrow Agent;
or
6.3.
ICANN has
received notification as described in Part B, Sections 7.1 and 7.2 of this
Specification from Escrow Agent of failed verification of the latest escrow
deposit for a specific date or a notification of a missing deposit, and the
notification is for a deposit that should have been made on Sunday (i.e., a
Full Deposit); (a) ICANN gave notice to Registry Operator of that receipt; and
(b) ICANN has not, within seven (7) calendar days after such notice, received
notification as described in Part B, Sections 7.1 and 7.2 of this Specification
from Escrow Agent of verification of a remediated version of such Full Deposit;
or
6.4.
ICANN has
received five notifications from Escrow Agent within the last thirty (30)
calendar days notifying ICANN of either missing or failed escrow deposits that
should have been made Monday through Saturday (i.e., a Differential Deposit),
and (x) ICANN provided notice to Registry Operator of the receipt of such
notifications; and (y) ICANN has not, within seven (7) calendar days after
delivery of such notice to Registry Operator, received notification from Escrow
Agent of verification of a remediated version of such Differential Deposit; or
6.5.
Registry
Operator has: (i) ceased to conduct its
business in the ordinary course; or (ii) filed for bankruptcy, become
insolvent or anything analogous to any of the foregoing under the laws of any
jurisdiction anywhere in the world; or
6.6.
Registry
Operator has experienced a failure of critical registry functions and ICANN has
asserted its rights pursuant to Section 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.5.
Domain Name Data:
1.5.1
Query format: whois
EXAMPLE.TLD
1.5.2
Response format:
Domain Name:
EXAMPLE.TLD
Domain ID: D1234567-TLD
WHOIS Server: whois.example.tld
Referral URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 5555555
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.6.
Registrar Data:
1.6.1
Query format:
whois “registrar Example Registrar, Inc.”
1.6.2
Response format:
Registrar
Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.7.
Nameserver Data:
1.7.1
Query format:
whois “NS1.EXAMPLE.TLD”, whois “nameserver (nameserver name)”, or whois
“nameserver (IP Address)”
1.7.2
Response format:
Server Name:
NS1.EXAMPLE.TLD
IP Address: 192.0.2.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.8.
The format
of the following data fields: domain
status, individual and organizational names, address, street, city,
state/province, postal code, country, telephone and fax numbers (the extension
will be provided as a separate field as shown above), email addresses, date and
times should conform to the mappings specified in EPP RFCs 5730-5734 so that
the display of this information (or values return in WHOIS responses) can be
uniformly processed and understood.
1.9.
In order to
be compatible with ICANN’s common interface for WHOIS (InterNIC), WHOIS output
shall be in the format outline above.
1.10.
Searchability.
Offering searchability capabilities on the Directory Services is
optional but if offered by the Registry Operator it shall comply with the
specification described in this section.
1.10.1
Registry
Operator will offer searchability on the web-based Directory Service.
1.10.2
Registry
Operator will offer partial match capabilities, at least, on the following
fields: domain name, contacts and
registrant’s name, and contact and registrant’s postal address, including all
the sub-fields described in EPP (e.g., street, city, state or province, etc.).
1.10.3
Registry
Operator will offer exact-match capabilities, at least, on the following
fields: registrar id, name server name,
and name server’s IP address (only applies to IP addresses stored by the
registry, i.e., glue records).
1.10.4
Registry
Operator will offer Boolean search capabilities supporting, at least, the
following logical operators to join a set of search criteria: AND, OR, NOT.
1.10.5
Search
results will include domain names matching the search criteria.
1.10.6
Registry
Operator will: 1) implement appropriate
measures to avoid abuse of this feature (e.g., permitting access only to
legitimate authorized users); and 2) ensure the feature is in compliance with
any applicable privacy laws or policies.
1.11.
Registry
Operator shall provide a link on the primary website for the TLD (i.e., the
website provided to ICANN for publishing on the ICANN website) to a web page
designated by ICANN containing WHOIS policy and educational materials.
2.
Zone File Access
2.1.
Third-Party Access
2.1.1
Zone File Access Agreement.
Registry Operator will enter into an agreement with any Internet user,
which will allow such user to access an Internet host server or servers
designated by Registry Operator and download zone file data. The agreement will be standardized,
facilitated and administered by a Centralized Zone Data Access Provider, which
may be ICANN or an ICANN designee (the “CZDA Provider”). Registry Operator (optionally through the
CZDA Provider) will provide access to zone file data per Section 2.1.3 of this
Specification and do so using the file format described in Section 2.1.4 of
this Specification. Notwithstanding the
foregoing, (a) the CZDA Provider may reject the request for access of any user
that does not satisfy the credentialing requirements in Section 2.1.2 below;
(b) Registry Operator may reject the request for access of any user that does
not provide correct or legitimate credentials under Section 2.1.2 below or
where Registry Operator reasonably believes will violate the terms of Section
2.1.5. below; and, (c) Registry Operator may revoke access of any user if
Registry Operator has evidence to support that the user has violated the terms
of Section 2.1.5 below.
2.1.2
Credentialing Requirements. Registry Operator, through the facilitation
of the CZDA Provider, will request each user to provide it with information sufficient
to correctly identify and locate the user.
Such user information will include, without limitation, company name,
contact name, address, telephone number, facsimile number, email address and IP
address.
2.1.3
Grant of Access. Each
Registry Operator (optionally through the CZDA Provider) will provide the Zone
File 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.4
File Format Standard.
Registry Operator (optionally through the CZDA Provider) will provide
zone files using a subformat of the standard Master File format as originally
defined in RFC 1035, Section 5, including all the records present in the actual
zone used in the public DNS. Sub-format
is as follows:
1.
Each record
must include all fields in one line as:
<domain-name> <TTL> <class> <type>
<RDATA>.
2.
Class and
Type must use the standard mnemonics and must be in lower case.
3.
TTL must be
present as a decimal integer.
4.
Use of /X
and /DDD inside domain names is allowed.
5.
All domain
names must be in lower case.
6.
Must use
exactly one tab as separator of fields inside a record.
7.
All domain
names must be fully qualified.
8.
No $ORIGIN
directives.
9.
No use of
“@” to denote current origin.
10.
No use of
“blank domain names” at the beginning of a record to continue the use of the
domain name in the previous record.
11.
No $INCLUDE
directives.
12.
No $TTL
directives.
13.
No use of
parentheses, e.g., to continue the list of fields in a record across a line
boundary.
14.
No use of
comments.
15.
No blank
lines.
16.
The SOA
record should be present at the top and (duplicated at) the end of the zone
file.
17.
With the
exception of the SOA record, all the records in a file must be in alphabetical
order.
18.
One zone per
file. If a TLD divides its DNS data into
multiple zones, each goes into a separate file named as above, with all the
files combined using tar into a file called <tld>.zone.tar.
2.1.5
Use of Data by User.
Registry Operator will permit user to use the zone file for lawful
purposes; provided that (a) user takes all reasonable steps to protect against
unauthorized access to 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.6
Term of Use. Registry Operator,
through CZDA Provider, will provide each user with access to the zone file for
a period of not less than three (3) months.
Registry Operator will allow users to renew their Grant of Access.
2.1.7
No Fee for Access.
Registry Operator will provide, and CZDA Provider will facilitate,
access to the zone file to user at no cost.
2.2.
Co-operation
2.2.1
Assistance. Registry Operator will co-operate
and provide reasonable assistance to ICANN and the CZDA Provider to facilitate
and maintain the efficient access of zone file data by permitted users as
contemplated under this Schedule.
2.3.
ICANN Access.
Registry Operator shall provide bulk access to the zone files for the
TLD to ICANN or its designee on a continuous basis in the manner ICANN may
reasonably specify from time to time. Access will be provided at least daily.
Zone files will include SRS data committed as close as possible to 00:00:00 UTC.
2.4.
Emergency Operator Access.
Registry Operator shall provide bulk access to the zone files for the
TLD to the Emergency Operators designated by ICANN on a continuous basis in the
manner ICANN may reasonably specify from time to time.
3.
Bulk Registration Data Access to ICANN
3.1.
Periodic Access to Thin Registration Data. In
order to verify and ensure the operational stability of Registry Services as
well as to facilitate compliance checks on accredited registrars, Registry
Operator will provide ICANN on a weekly basis (the day to be designated by
ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of
00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
3.1.1
Contents. Registry Operator will
provide, at least, the following data for all registered domain names: domain name, domain name repository object id
(roid), registrar id (IANA ID), statuses, last updated date, creation date,
expiration date, and name server names.
For sponsoring registrars, at least, it will provide: registrar name, registrar repository object
id (roid), hostname of registrar Whois server, and URL of registrar.
3.1.2
Format. The data will be provided
in the format specified in Specification 2 for Data Escrow (including encryption,
signing, etc.) but including only the fields mentioned in the previous section,
i.e., the file will only contain Domain and Registrar objects with the fields
mentioned above. Registry Operator has
the option to provide a full deposit file instead as specified in Specification
2.
3.1.3
Access. Registry Operator will
have the file(s) ready for download as of 00:00:00 UTC on the day designated
for retrieval by ICANN. The file(s) will
be made available for download by SFTP, though ICANN may request other means in
the future.
3.2.
Exceptional Access to Thick Registration Data. In
case of a registrar failure, deaccreditation, court order, etc. that prompts
the temporary or definitive transfer of its domain names to another registrar,
at the request of ICANN, Registry Operator will provide ICANN with up-to-date
data for the domain names of the losing registrar. The data will be provided in the format
specified in Specification 2 for Data Escrow.
The file will only contain data related to the domain names of the losing
registrar. Registry Operator will
provide the data as soon as commercially practicable, but in no event later
than five (5) calendar days following ICANN’s request. Unless otherwise agreed by Registry Operator
and ICANN, the file will be made available for download by ICANN in the same
manner as the data specified in Section 3.1 of this Specification.
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.1
Registry
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.2
Notwithstanding
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.3
The sets of
names subject to mitigation or blocking pursuant to Sections 6.2.1 and 6.2.2
will be based on ICANN analysis of DNS information including "Day in the
Life of the Internet" data maintained by the DNS Operations, Analysis, and
Research Center (DNS-OARC) <https://www.dns-oarc.net/oarc/data/ditl>.
6.2.4
Registry
Operator may participate in the development by the ICANN community of a process
for determining whether and how these blocked names may be released.
6.2.5
If 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.1
During 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.2
Registry
Operator shall develop an internal process for handling in an expedited manner
reports received pursuant to subsection 6.3.1 under which Registry Operator
may, to the extent necessary 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
b.
the Uniform
Rapid Suspension system (“URS”) adopted by ICANN (posted at http://www.icann.org/en/resources/registries/urs), including the implementation of
determinations issued by URS examiners.
SPECIFICATION 8
CONTINUED OPERATIONS INSTRUMENT
1.
The
Continued Operations Instrument shall (a) provide for sufficient financial
resources to ensure the continued operation of the critical registry functions
related to the TLD set forth in Section 6 of Specification 10 to this Agreement
for a period of three (3) years following any termination of this Agreement on
or prior to the fifth anniversary of the Effective Date or for a period of one
(1) year following any termination of this Agreement after the fifth
anniversary of the Effective Date but prior to or on the sixth (6th)
anniversary of the Effective Date, and (b) be in the 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.5.
DNS resolution RTT.
Refers to either “UDP DNS
resolution RTT” or “TCP DNS
resolution RTT”.
3.6.
DNS update time.
Refers to the time measured from the reception of an EPP confirmation to
a transform command on a domain name, until the name servers of the parent
domain name answer “DNS queries”
with data consistent with the change made.
This only applies for changes to DNS information.
3.7.
DNS test. Means one non-recursive
DNS query sent to a particular “IP
address” (via UDP or TCP). If DNSSEC
is offered in the queried DNS zone, for a query to be considered answered, the
signatures must be positively verified against a corresponding DS record
published in the parent zone or, if the parent is not signed, against a
statically configured Trust Anchor. The
answer to the query must contain the corresponding information from the
Registry System, otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will
be considered unanswered. The possible
results to a DNS test are: a number in
milliseconds corresponding to the “DNS
resolution RTT” or, undefined/unanswered.
3.8.
Measuring DNS parameters.
Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-DNS
registered “IP addresses” of the
name servers of the domain name being monitored. If a “DNS
test” result is undefined/unanswered, the tested IP will be considered
unavailable from that probe until it is time to make a new test.
3.9.
Collating the results from DNS probes. The
minimum number of active testing probes to consider a measurement valid is 20
at any given measurement period, otherwise the measurements will be discarded
and will be considered inconclusive; during this situation no fault will be
flagged against the SLRs.
3.10.
Distribution of UDP and TCP queries. DNS
probes will send UDP or TCP “DNS test”
approximating the distribution of these queries.
3.11.
Placement of DNS probes.
Probes for measuring DNS parameters shall be placed as near as possible
to the DNS resolvers on the networks with the most users across the different
geographic regions; care shall be taken not to deploy probes behind high
propagation-delay links, such as satellite links.
4.
RDDS
4.1.
RDDS availability.
Refers to the ability of all the RDDS services for the TLD, to respond
to queries from an Internet user with appropriate data from the relevant
Registry System. If 51% or more of the
RDDS testing probes see any of the RDDS services as unavailable during a given
time, the RDDS will be considered unavailable.
4.2.
WHOIS query RTT.
Refers to the RTT of the
sequence of packets from the start of the TCP connection to its end, including
the reception of the WHOIS response. If
the RTT is 5-times or more the
corresponding SLR, the RTT will be
considered undefined.
4.3.
Web-based-WHOIS query RTT.
Refers to the RTT of the
sequence of packets from the start of the TCP connection to its end, including
the reception of the HTTP response for only one HTTP request. If Registry Operator implements a
multiple-step process to get to the information, only the last step shall be
measured. If the RTT is 5-times or more the corresponding SLR, the RTT will be considered undefined.
4.4.
RDDS query RTT.
Refers to the collective of “WHOIS
query RTT” and “Web-based- WHOIS
query RTT”.
4.5.
RDDS update time.
Refers to the time measured from the reception of an EPP confirmation to
a transform command on a domain name, host or contact, up until the servers of
the RDDS services reflect the changes made.
4.6.
RDDS test. Means one query sent to a
particular “IP address” of one of
the servers of one of the RDDS services.
Queries shall be about existing objects in the Registry System and the
responses must contain the corresponding information otherwise the query will
be considered unanswered. Queries with
an RTT 5 times higher than the
corresponding SLR will be considered as unanswered. The possible results to an RDDS test
are: a number in milliseconds
corresponding to the RTT or
undefined/unanswered.
4.7.
Measuring RDDS parameters.
Every 5 minutes, RDDS probes will select one IP address from all the
public-DNS registered “IP addresses”
of the servers for each RDDS service of the TLD being monitored and make an “RDDS test” to each one. If an “RDDS
test” result is undefined/unanswered, the corresponding RDDS service will be
considered as unavailable from that probe until it is time to make a new test.
4.8.
Collating the results from RDDS probes. The
minimum number of active testing probes to consider a measurement valid is 10
at any given measurement period, otherwise the measurements will be discarded
and will be considered inconclusive; during this situation no fault will be
flagged against the SLRs.
4.9.
Placement of RDDS probes.
Probes for measuring RDDS parameters shall be placed inside the networks
with the most users across the different geographic regions; care shall be
taken not to deploy probes behind high propagation-delay links, such as
satellite links.
5.
EPP
5.1.
EPP service availability.
Refers to the ability of the TLD EPP servers as a group, to respond to
commands from the Registry accredited Registrars, who already have credentials
to the servers. The response shall
include appropriate data from the Registry System. An EPP command with “EPP command RTT” 5 times higher than the corresponding SLR will be
considered as unanswered. If 51% or more
of the EPP testing probes see the EPP service as unavailable during a given
time, the EPP service will be considered unavailable.
5.2.
EPP session-command RTT.
Refers to the RTT of the
sequence of packets that includes the sending of a session command plus the
reception of the EPP response for only one EPP session command. For the login command it will include packets
needed for starting the TCP session. For
the logout command it will include packets needed for closing the TCP session. EPP session commands are those described in
section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the
corresponding SLR, the RTT will be
considered undefined.
5.3.
EPP query-command RTT.
Refers to the RTT of the
sequence of packets that includes the sending of a query command plus the
reception of the EPP response for only one EPP query command. It does not include packets needed for the
start or close of either the EPP or the TCP session. EPP query commands are those described in
section 2.9.2 of EPP RFC 5730. If the RTT is 5-times or more the
corresponding SLR, the RTT will be
considered undefined.
5.4.
EPP transform-command RTT.
Refers to the RTT of the
sequence of packets that includes the sending of a transform command plus the
reception of the EPP response for only one EPP transform command. It does not include packets needed for the
start or close of either the EPP or the TCP session. EPP transform commands are those described in
section 2.9.3 of EPP RFC 5730. If the RTT is 5 times or more the corresponding
SLR, the RTT will be considered
undefined.
5.5.
EPP command RTT.
Refers to “EPP session-command
RTT”, “EPP query-command RTT” or
“EPP transform-command RTT”.
5.6.
EPP test. Means one EPP command
sent to a particular “IP address”
for one of the EPP servers. Query and
transform commands, with the exception of “create”, shall be about existing
objects in the Registry System. The
response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the
“EPP command RTT” or
undefined/unanswered.
5.7.
Measuring EPP parameters.
Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make
an “EPP test”; every time they
should alternate between the 3 different types of commands and between the
commands inside each category. If an “EPP test” result is
undefined/unanswered, the EPP service will be considered as unavailable from
that probe until it is time to make a new test.
5.8.
Collating the results from EPP probes. The
minimum number of active testing probes to consider a measurement valid is 5 at
any given measurement period, otherwise the measurements will be discarded and
will be considered inconclusive; during this situation no fault will be flagged
against the SLRs.
5.9.
Placement of EPP probes.
Probes for measuring EPP parameters shall be placed inside or close to
Registrars points of access to the Internet across the different geographic
regions; care shall be taken not to deploy probes behind high propagation-delay
links, such as satellite links.
6.
Emergency Thresholds
The
following matrix presents the emergency thresholds that, if reached by any of
the services mentioned above for a TLD, would cause the emergency transition of
the Registry for the TLD as specified in Section 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.
e.
Registry
Operators will include a provision in their Registry-Registrar Agreements that
requires registrars to include in their Registration Agreements a provision
requiring registrants to comply with all applicable laws, including those that
relate to privacy, data collection, consumer protection (including in relation
to misleading and deceptive conduct), fair lending, debt collection, organic
farming, disclosure of data, and financial disclosures.
f.
Registry
Operators will include a provision in their Registry-Registrar Agreements that
requires registrars at the time of registration to notify registrants of the
requirement to comply with all applicable laws.
g.
Registry
Operators will include a provision in their Registry-Registrar Agreements that
requires registrars to include in their Registration Agreements a provision
requiring that registrants who collect and maintain sensitive health and
financial data implement reasonable and appropriate security measures
commensurate with the offering of those services, as defined by applicable law.
4.
Registry
Operator agrees to perform the following specific public interest commitments,
which commitments shall be enforceable by ICANN and through 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. Nothing in
Section 4 of this Specification shall limit any obligations of Registry
Operator under Sections 1, 2 and 3 of this Specification. In the event
Section 4 of this Specification conflicts with the requirements of any other
provision of the Registry Agreement (including any Section of this
Specification), such other provision shall govern.
a. Open registration - Second level
registrations in the TLD will be open and available to lawful registrants. The TLD
represents a generic or dictionary term, and Registry Operator accordingly will operate it in an inclusive
manner. Registry
Operator will not limit registrant
eligibility based on identity nor restrict availability of second
level names to only registrants whose identity
is associated only with the most common usage of the term. Registry
Operator will not
disenfranchise lawful users
who
are associated
with
a minority usage
of the
term.
b. Geographic name protection - Pursuant to Specification 5 of this Registry
Agreement, Registry
Operator will transmit to registrars the list of
geographic names prohibited from second level registration. Registry
Operator will periodically review this list to ensure it is identical to that maintained
by ICANN.
Should Registry
Operator seek to release these reserved names, it will consult with ICANN’s Governmental Advisory
Committee and obtain any permissions
necessary from ICANN for such
release.
c.
Rights Protection Mechanisms
and
Abuse Mitigation
- Registry Operator commits to implementing and performing the following
protections for the TLD:
i.
In order to help registrars
and registrants identify inaccurate data in the Whois database, Registry
Operator will audit Whois data
for accuracy on a statistically significant basis (this
commitment will be considered satisfied by virtue of and for so long as ICANN
conducts such audits).
ii. Work with registrars
and registrants to remediate inaccurate Whois data to help ensure a more accurate Whois database. Registry Operator
reserves the right to cancel a domain name registration
on
the basis of inaccurate data, if
necessary.
iii.
Establish and maintain a Domains Protected
Marks List (DPML), a trademark
protection service that allows rights holders
to reserve registration
of
exact match trademark terms
and terms that contain
their trademarks across all gTLDs administered by Registry
Operator under certain terms and conditions.
iv. At no cost to trademark holders,
establish and maintain a Claims Plus service,
which is a notice protection mechanism
that begins at the end of ICANN’s mandated
Trademark Claims period.
v. Bind registrants to terms of use that define and prohibit
illegal or abusive
activity.
vi. Limit the use of proxy and privacy
registration services
in cases of
malfeasance.
vii. Consistent with the terms of this Registry Agreement, reserve
the right to exclude
from distribution any registrars
with a history of
non-compliance with the terms of the Registrar Accreditation Agreement.
viii. Registry
Operator will be properly resourced to perform these
protections.
ix.
Supplement the periodic audit of Whois data by more extensively
reviewing and verifying data accuracy, and work to remediate inaccuracies (this
commitment will be considered satisfied by virtue of and for so long as ICANN
conducts such audits).
x.
Regularly monitor registered domain names for pharming, phishing,
spam, botnets, copyright infringement, and other forms of abuse, and work to
remediate any such activity. Registry Operator reserves the right to
cancel registrations on the basis of abusive behavior, if necessary.
xi.
Require that registrars maintain a continually available point of
contact capable of addressing problems involving abusive activity, and that
registrars maintain the capability to remediate abuse or cancel a registration
promptly, if necessary.
d. Anti-Abuse Policy
i. Registry Operator’s Anti-Abuse Policy will be required
under the Registry Registrar
Agreement and posted on the Registry
Operator’s web site.
ii. Registry Operator
will monitor the TLD for abusive behavior and address it as soon
as possible if detected.
iii.
Registry Operator
reserves the right, at its sole discretion and at any time and without limitation,
to deny, suspend, cancel, or transfer any registration or transaction, or place any domain name(s) on registry lock, hold, or similar status as it determines necessary for any
of the following
reasons:
A. to protect the integrity
and stability of the
registry;
B. to comply with any applicable
laws, government
rules or requirements, requests of law enforcement, or any dispute resolution
process;
C.