This REGISTRY AGREEMENT
(this “Agreement”) is entered into as of _________________ (the
“Effective Date”) between Internet Corporation for Assigned Names and Numbers,
a California nonprofit public benefit corporation (“ICANN”), and __________, a _____________Big Room Inc., a Canada
Business Corporation (“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 ____.ECO (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.
(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.
2.19
2.19 [Note:
For Community-Based TLDs Only] Obligations
of Registry Operator to TLD Community.
Registry Operator shall establish registration policies in conformity
with the application submitted with respect to the TLD for: (i) naming conventions within the TLD, (ii) requirements
for registration by members of the TLD community, and (iii) use of registered
domain names in conformity with the stated purpose of the community-based
TLD. Registry Operator shall operate the
TLD in a manner that allows the TLD community to discuss and participate in the
development and modification of policies and practices for the TLD. Registry Operator shall establish procedures
for the enforcement of registration policies for the TLD, and resolution of
disputes concerning compliance with TLD registration policies, and shall enforce
such registration policies. Registry
Operator agrees to implement and be bound by the Registry Restrictions Dispute
Resolution Procedure as set forth at [insert applicable URL]http://www.icann.org/en/resources/registries/rrdrp
with respect to disputes arising pursuant to this Section 2.19. Registry Operator shall implement and comply
with the community registration policies set forth on Specification 12 attached
hereto.]
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”).
(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.
(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.
(h) [Applicable to intergovernmental
organizations or governmental entities only.] ICANN may terminate this Agreement pursuant
to Section 7.16.
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.
“Transition of Registry upon Termination of
Agreement. Upon expiration of the
Term pursuant to Section 4.1 or Section 4.2 or any termination of this
Agreement pursuant to Section 4.3
or Section 4.4, in connection with ICANN’s designation of a successor registry
operator for the TLD, Registry Operator and ICANN agree to consult each other
and work cooperatively to facilitate and implement the transition of the TLD in
accordance with this Section 4.5. After
consultation with Registry Operator, ICANN shall determine whether or not to
transition operation of the TLD to a successor registry operator in its sole
discretion and in conformance with the Registry Transition Process. In the event ICANN determines to transition
operation of the TLD to a successor registry operator, upon Registry Operator’s
consent (which shall not be unreasonably withheld, conditioned or delayed),
Registry Operator shall provide ICANN or such successor registry operator for
the TLD with any data regarding operations of the TLD necessary to maintain
operations and registry functions that may be reasonably requested by ICANN or
such successor registry operator in addition to data escrowed in accordance
with Section 2.3 hereof. In the event
that Registry Operator does not consent to provide such data, any registry data
related to the TLD shall be returned to Registry Operator, unless otherwise
agreed upon by the 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,
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.
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).
(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) US$0.251an 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.
(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.
[Alternative
Section 7.1(a) text for
intergovernmental organizations or governmental entities:
(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.
[Note: This Section 7.1(b) is
inapplicable to intergovernmental organizations or governmental entities.]
7.2
Indemnification
Procedures. If any third-party claim is commenced that 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. [Note:
This Section 7.2 is inapplicable to intergovernmental organizations or
governmental entities.]
7.3
Defined Terms. For purposes of this Agreement, unless such
definitions 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.
(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).
(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
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:
[________________]
[________________]
[________________]
Big Room Inc.
Telephone: +1-778-960-6527
With
a Required Copy to:
Email: (As specified from time to time.)
Attention: Jacob Malthouse,
President
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
(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.
7.16 Special
Provision Relating to Intergovernmental Organizations or Governmental Entities.
(a) ICANN
acknowledges that Registry Operator is an entity subject to public
international law, including international treaties applicable to Registry
Operator (such public international law and treaties, collectively hereinafter
the “Applicable Laws”). Nothing in this
Agreement and its related specifications shall be construed or interpreted to
require Registry Operator to violate Applicable Laws or prevent compliance
therewith. The Parties agree that
Registry Operator’s compliance with Applicable Laws shall not constitute a
breach of this Agreement.
(b) In the event
Registry Operator reasonably determines that any provision of this Agreement
and its related specifications, or any decisions or policies of ICANN referred
to in this Agreement, including but not limited to Temporary Policies and
Consensus Policies (such provisions, specifications and policies, collectively
hereinafter, “ICANN Requirements”), may conflict with or violate Applicable Law
(hereinafter, a “Potential Conflict”), Registry Operator shall provide detailed
notice (a “Notice”) of such Potential Conflict to ICANN as early as possible
and, in the case of a Potential Conflict with a proposed Consensus Policy, no
later than the end of any public comment period on such proposed Consensus
Policy. In the event Registry Operator
determines that there is Potential Conflict between a proposed Applicable Law
and any ICANN Requirement, Registry Operator shall provide detailed Notice of
such Potential Conflict to ICANN as early as possible and, in the case of a
Potential Conflict with a proposed Consensus Policy, no later than the end of
any public comment period on such proposed Consensus Policy.
(c) As soon as
practicable following such review, the parties shall attempt to resolve the
Potential Conflict by mediation pursuant to the procedures set forth in Section
5.1. In addition, Registry Operator
shall use its best efforts to eliminate or minimize any impact arising from
such Potential Conflict between Applicable Laws and any ICANN Requirement. If, following such mediation, Registry
Operator determines that the Potential Conflict constitutes an actual conflict
between any ICANN Requirement, on the one hand, and Applicable Laws, on the
other hand, then ICANN shall waive compliance with such ICANN Requirement
(provided that the parties shall negotiate in good faith on a continuous basis
thereafter to mitigate or eliminate the effects of such noncompliance on
ICANN), unless ICANN reasonably and objectively determines that the failure of
Registry Operator to comply with such ICANN Requirement would constitute a
threat to the Security and Stability of Registry Services, the Internet or the
DNS (hereinafter, an “ICANN Determination”).
Following receipt of notice by Registry Operator of such ICANN
Determination, Registry Operator shall be afforded a period of ninety (90)
calendar days to resolve such conflict with an Applicable Law. If the conflict with an Applicable Law is not
resolved to ICANN’s complete satisfaction during such period, Registry Operator
shall have the option to submit, within ten (10) calendar days thereafter, the
matter to binding arbitration as defined in subsection (d) below. If during such period, Registry Operator does
not submit the matter to arbitration pursuant to subsection (d) below, ICANN
may, upon notice to Registry Operator, terminate this Agreement with immediate effect.
(d) If Registry
Operator disagrees with an ICANN Determination, Registry Operator may submit
the matter to binding arbitration pursuant to the provisions of Section 5.2,
except that the sole issue presented to the arbitrator for determination will
be whether or not ICANN reasonably and objectively reached the ICANN
Determination. For the purposes of such
arbitration, ICANN shall present evidence to the arbitrator supporting the
ICANN Determination. If the arbitrator
determines that ICANN did not reasonably and objectively reach the ICANN
Determination, then ICANN shall waive Registry Operator’s compliance with the
subject ICANN Requirement. If the
arbitrators or pre-arbitral referee, as applicable, determine that ICANN did
reasonably and objectively reach the ICANN Determination, then, upon notice to
Registry Operator, ICANN may terminate this Agreement with immediate
effect.
(e) Registry Operator
hereby represents and warrants that, to the best of its knowledge as of the
date of execution of this Agreement, no existing ICANN Requirement conflicts
with or violates any Applicable Law.
(f) Notwithstanding
any other provision of this Section 7.16, following an ICANN Determination and
prior to a finding by an arbitrator pursuant to Section 7.16(d) above, ICANN
may, subject to prior consultations with Registry Operator, take such
reasonable technical measures as it deems necessary to ensure the Security and
Stability of Registry Services, the Internet and the DNS. These reasonable technical measures shall be
taken by ICANN on an interim basis, until the earlier of the date of conclusion
of the arbitration procedure referred to in Section 7.16(d) above or the date
of complete resolution of the conflict with an Applicable Law. In case Registry Operator disagrees with such
technical measures taken by ICANN, Registry Operator may submit the matter to
binding arbitration pursuant to the provisions of Section 5.2 above, during
which process ICANN may continue to take such technical measures. In the event that ICANN takes such measures,
Registry Operator shall pay all costs incurred by ICANN as a result of taking
such measures. In addition, in the event
that ICANN takes such measures, ICANN shall retain and may enforce its rights
under the Continued Operations Instrument and Alternative Instrument, as
applicable.
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
By: _____________________________
[_____________]
President and CEO
Date:
By: _____________________________
[____________]
[____________]
Date:
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.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)
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.
Registry Operator may suspend,
delete or otherwise make changes to domain names in compliance with its
anti-abuse policy.
CONSENSUS POLICIES AND
TEMPORARY POLICIES SPECIFICATION
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”;
(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.
(1)
The
signature file of each processed file is validated.
(2)
If
processed files are pieces of a bigger file, the latter is put together.
(3)
Each
file obtained in the previous step is then decrypted and uncompressed.
(4)
Each
data file contained in the previous step is then validated against the format
defined in Part A, Section 9, reference 1 of this Specification.
(5)
If
Part A, Section 9, reference 1 of this Specification includes a verification
process, that will be applied at this step.
If any discrepancy is found in any of the steps, the Deposit
will be considered incomplete.
(1)
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
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.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-successfullysuccessful |
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.1
Query format: whois EXAMPLE.TLD
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.1
Query format: whois “registrar Example Registrar, Inc.”
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.1
Query format: whois “NS1.EXAMPLE.TLD”, whois “nameserver
(nameserver name)”, or whois “nameserver (IP Address)”
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.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.
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.
13.
No
use of parentheses, e.g., to continue the list of fields in a record across a
line boundary.
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.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.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.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.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.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 inquiresinquiries
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.
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 [url to be
inserted]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 [urls to be
inserted when final procedure is adopted]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 [url to be inserted]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.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.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.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.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.
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. |
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.
Registry Operator
will operate the registry for the TLD in compliance with all commitments, statements of intent and business
plans stated in the following
sections of Registry
Operator’s application to ICANN for the TLD, which commitments, statements of intent and business
plans are hereby incorporated by reference into this Agreement. Registry Operator’s
obligations pursuant to this paragraph
shall be enforceable by ICANN and through the PICDRP
(as defined in Section 3 below). 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 Registry
Agreement) following a determination by any PICDRP
panel and to be bound by any such determination.
a.
Application Sections 18
(Mission/Purpose) & 20 (Community-based Designation).
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 [url to be
inserted when final procedure is adopted]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.
[Registry Operator to insert specific application sections here,
if applicable]
3. Registry
Operator agrees to perform the following specific public interest commitments,
which commitments shall be enforceable by ICANN 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.
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.
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.
The above
paragraph in this Section 4 of this Specification applies to the following
public interest commitments of Registry Operator related to the TLD. Nothing in this Section 4 of this Specification
shall limit any obligations of Registry Operator under Sections 1, 2 and 3 of
this Specification. In the event this
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 and will supersede this
Section 4 to the extent of the conflict.
Registry
Operator commits to implementing and performing the following protections for
the TLD:
SPECIFICATION 12
COMMUNITY REGISTRATION POLICIES
Community Registration Policies
Registry
Operator shall implement and comply with all community registration policies
described below and/or attached to this Specification 12. In the
event Specification 12 conflicts with the requirements of any other provision
of the Registry Agreement, such other provision shall govern.
[Insert
registration policies]
1. Not-for-profit environmental organizations
that affirm and can provide proof on request of:
A) Accreditation by relevant UN agencies (i.e.,
UNEP, UN Economic and Social Council) or
B) Proof of legal establishment and environmental
mission⁄purpose.
2. Business entities that affirm and can provide
proof on request of:
A) Membership in environmental organizations and
initiatives including:
i.
Organizations as in 1 A)-B) or
ii.
The United Nations Global Compact or
iii.
Other memberships approved by the
Organization
B) Accreditation by voluntary environmental
certifications, standards and reporting systems of:
i.
Organizations as in 1 A)-B) or
ii.
UN member states, national and
sub-national governmental bodies and entities or
iii.
The International Organization for
Standardization or
iv.
Other certification, standards and
reporting systems approved by the Organization
a)
Organizations as in 1 A)-B) or
b)
Certified environmental professional
qualifications approved by the Organization or
c)
Academics ⁄ scientists affiliated
with recognized universities
The types of .ECO use will be not-for-profit,
business, individual, government, and product.
Registrants must complete all mandatory
.ECO-profile questions.