.COM
Registry Agreement
(1
December 2024)
REGISTRY AGREEMENT
This REGISTRY AGREEMENT (this
"Agreement") is entered into as of December 1, 2024 by and between
Internet Corporation for Assigned Names and Numbers, a California nonprofit
public benefit corporation ("ICANN"), and VeriSign, Inc. a Delaware
corporation (“Verisign”). This Agreement amends and restates in its entirety
the Registry Agreement, dated December 1, 2012 by and between ICANN and Verisign,
as amended by the First Amendment to the .COM Registry Agreement, dated October
20, 2016, the Second Amendment to the .COM Registry Agreement, dated March 27,
2019, and the Third Amendment to the .COM Registry Agreement, dated March 27,
2020, by and between ICANN and Verisign (collectively, the “Prior Agreement”).
ARTICLE I INTRODUCTION
Section 1.1 Effective
Date. The “Effective Date” for purposes of this Agreement shall be December
1, 2024.
Section 1.2 Top-Level
Domain. The Top-Level Domain to which this Agreement applies is .com
("TLD").
Section 1.3 Designation
as Registry Operator. Upon the Effective Date and through the Term (as
defined in Section 4.1 hereof), unless earlier terminated pursuant to Article 6
hereof, ICANN shall continue to designate Verisign as the sole registry
operator for the TLD ("Registry Operator").
ARTICLE II REPRESENTATIONS AND WARRANTIES
Section 2.1 Registry
Operator's Representations and Warranties.
(a) Organization;
Due Authorization and Execution. Registry Operator is a corporation, duly
organized, validly existing and in good standing under the laws of Delaware,
and Registry Operator has all requisite power and authority to enter into this
Agreement. All corporate approvals and actions necessary for the entrance by
Registry Operator into this Agreement have been obtained and this Agreement has
been duly and validly executed and delivered by Registry Operator.
(b) Statements
made During Negotiation Process. The factual statements made in writing by
both parties in negotiating this Agreement were true and correct in all
material respects at the time made. A violation or breach of this subsection
shall not be a basis for termination, rescission or other equitable relief,
and, instead shall only give rise to a claim for damages.
Section 2.2 ICANN's
Representations and Warranties.
(a) Organization;
Due Authorization and Execution. ICANN is a nonprofit public benefit
corporation duly organized, validly existing and in good standing under the
laws of California. ICANN has all requisite corporate power and authority to
enter into this Agreement. All corporate approvals and actions necessary for
the entrance by ICANN into this Agreement have been obtained and this Agreement
has been duly and validly executed and delivered by ICANN.
ARTICLE III COVENANTS
Section 3.1 Covenants
of Registry Operator. Registry Operator covenants and agrees with ICANN as
follows:
(a) Preserve Security
and Stability.
(i) ICANN Temporary
Specifications or Policies. Registry Operator shall comply with and implement
all specifications or policies established by the ICANN Board of Directors on a
temporary basis, if adopted by the ICANN Board of Directors by a vote of at
least two-thirds of its members, so long as the ICANN Board of Directors
reasonably determines that immediate temporary establishment of a specification
or policy on the subject is necessary to maintain the Stability or Security (as
defined in Section 3.1(d)(iv)(G)) of Registry Services or the DNS ("Temporary
Specification or Policies"). Such proposed specification or policy shall
be as narrowly tailored as feasible to achieve those objectives. In
establishing any specification or policy under this provision, the ICANN Board
of Directors shall state the period of time for which the specification or
policy is temporarily adopted and shall immediately implement the Consensus Policy
development process set forth in ICANN's Bylaws. ICANN shall also issue an
advisory statement containing a detailed explanation of its reasons for
adopting the temporary specification or policy and why the Board believes the
specification or policy should receive the consensus support of Internet
stakeholders. If the period of time for which the specification or policy is
adopted exceeds 90 days, the ICANN Board shall reaffirm its temporary adoption
every 90 days for a total period not to exceed one year, in order to maintain
such policy in effect until such time as it shall become a Consensus Policy as
described in Section 3.1(b) below. If during such one year period, the
temporary policy or specification does not become a Consensus Policy meeting
the standard set forth in Section 3.1(b) below, Registry Operator shall no
longer be required to comply with or implement such temporary policy or
specification.
(b) Consensus Policies.
(i) At all times
during the Term of this Agreement and subject to the terms hereof, Registry
Operator will fully comply with and implement all Consensus Policies found at https://www.icann.org/consensus-policies, as of the
Effective Date and as may in the future be developed and adopted in accordance
with ICANN's Bylaws and as set forth below.
(ii)
"Consensus Policies" are those specifications or policies established
(1) pursuant to the procedure set forth in ICANN's Bylaws and due process, and
(2) covering those topics listed in Section 3.1(b)(iv) below. The Consensus Policy
development process and procedure set forth in ICANN's Bylaws may be revised
from time to time in accordance with ICANN's Bylaws, and any Consensus Policy
that is adopted through such a revised process and covering those topics listed
in Section 3.1(b)(iv) below shall be considered a Consensus Policy for purposes
of this Agreement.
(iii) For all
purposes under this Agreement, the policies identified at https://www.icann.org/consensus-policies shall be treated
in the same manner and have the same effect as "Consensus Policies."
(iv) 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) issues for which uniform or coordinated resolution is reasonably
necessary to facilitate interoperability, security and/or stability of the
Internet or DNS; (2) functional and performance specifications for the
provision of Registry Services (as defined in Section 3.1(d)(iii) below); (3) Security
and Stability of the registry database for the TLD; (4) registry policies
reasonably necessary to implement Consensus Policies relating to registry
operations or registrars; or (5) resolution of disputes regarding the
registration of domain names (as opposed to the use of such domain names). Such
categories of issues referred to in the preceding sentence shall include,
without limitation:
(A) principles for
allocation of registered names in the TLD (e.g., first-come, first-served,
timely renewal, holding period after expiration);
(B) prohibitions
on warehousing of or speculation in domain names by registries or registrars;
(C) 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 (a) avoidance of confusion
among or misleading of users, (b) intellectual property, or (c) the technical
management of the DNS or the Internet (e.g., establishment of reservations of
names from registration);
(D) maintenance of
and access to accurate and up-to-date information concerning domain name
registrations;
(E) procedures to
avoid disruptions of domain name registration 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; and
(F) resolution of
disputes regarding whether particular parties may register or maintain
registration of particular domain names.
(v) In addition to
the other limitations on Consensus Policies, they shall not:
(A) prescribe or
limit the price of Registry Services;
(B) modify the
standards for the consideration of proposed Registry Services, including the
definitions of Security and Stability (set forth below) and the standards
applied by ICANN;
(C) modify the
terms or conditions for the renewal or termination of this Agreement;
(D) modify ICANN's
obligations to Registry Operator under Section 3.2 (a), (b), and (c);
(E) modify the
limitations on Consensus Policies or Temporary Specifications or Policies;
(F) modify the
definition of Registry Services;
(G) modify the
terms of Sections 7.2 and 7.3, below; and
(H) alter services
that have been implemented pursuant to Section 3.1(d) of this Agreement (unless
justified by compelling and just cause based on Security and Stability).
(vi) Registry
Operator shall be afforded a reasonable period of time following notice of the
establishment of a Consensus Policy or Temporary Specifications or Policies in
which to comply with such policy or specification, taking into account any
urgency involved.
In the event of a conflict between
Registry Services (as defined in Section 3.1(d)(iii) below), on the one hand,
and Consensus Policies developed in accordance with this Section 3.1(b) or any
Temporary Specifications or Policies established pursuant to Section 3.1(a)(i)
above, on the other hand, the Consensus Policies or Temporary Specifications or
Policies shall control, notwithstanding any other provisions contained within
this Agreement.
(c) Handling of
Registry Data.
(i) Data Escrow.
Registry Operator shall establish at its expense a data escrow or mirror site
policy for the Registry Data compiled by Registry Operator. Registry Data, as
used in this Agreement, shall mean the following: (1) data for domains
sponsored by all registrars, consisting of domain name, server name for each
nameserver, registrar id, updated date, creation date, expiration date, status
information, and DNSSEC delegation signer ("DS") data; (2) data for
nameservers sponsored by all registrars consisting of server name, each IP
address, registrar id, updated date, creation date, expiration date, and status
information; (3) data for registrars sponsoring registered domains and
nameservers, consisting of registrar id, registrar address, registrar telephone
number, registrar e-mail address, whois server (which shall continue to be
provided after January 28, 2025, if provided by registrar), referral URL,
updated date and the name, telephone number, and e-mail address of all the
registrar's administrative, billing, and technical contacts; and (4) any domain
name registrant data collected by the Registry Operator from registrars as part
of or following registration of a domain name. The escrow agent or mirror-site
manager, and the obligations thereof, shall be mutually agreed upon by ICANN
and Registry Operator on commercially reasonable standards that are technically
and practically sufficient to allow a successor registry operator to assume
management of the TLD. Registry Operator shall comply with the registry data
escrow specifications set forth in Appendix 1 (Data Escrow Specification) and
the parties will comply with the executed Escrow Agreement substantially in the
form of Appendix 2 (Escrow Agreement (Template Format)).
(ii) Personal
Data. Registry Operator shall notify registrars sponsoring registrations in
the registry for the TLD of the purposes for which Personal Data (as defined
below) submitted to Registry Operator by registrars, if any, is collected, the
intended recipients (or categories of recipients) of such Personal Data, and
the mechanism for access to and correction of such Personal Data. Registry
Operator shall take reasonable steps to protect Personal Data 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. "Personal Data"
shall refer to all data about any identified or identifiable natural person.
(iii) Bulk Zone
File Access. Registry Operator will make available bulk access to zone
files to third parties and ICANN in accordance with the terms of Appendix 3
(Zone File Access).
(iv) Monthly
Reporting. Within twenty (20) calendar days following the end of each
calendar month, Registry Operator shall prepare and deliver to ICANN reports
providing such data, and in the format, set forth in Appendix 4 (Format and
Content for Registry Operator Monthly Reporting).
(v) Registration
Data Directory Services. Registry Operator shall provide the registration
data as set forth in Appendix 5A (Registration Data Publication Services
Specification) and Appendix 5B (Registration Data Access Protocol Service
Specification) relevant to the type of top level domain operated (e.g. “thick”
or “thin” registry model). As of the Effective Date, the TLD is a “thin”
registry model.
(vi) [RESERVED]
(vii) Public Interest Commitments.
Registry Operator shall comply with the public interest commitments set forth
in Appendix 11 (Public Interest Commitments).
(d) Registry
Operations.
(i) Registration
Restrictions. Registry Operator shall reserve, and not register any TLD strings
appearing on the list of reserved TLD strings attached as Appendix 6 hereto.
(ii) Functional
and Performance Specifications. Functional and Performance Specifications
for operation of the TLD shall be as set forth in Appendix 7 (Functional and
Performance Specifications), Section 3 of Appendix 5B (Service Level
Requirements) and Section 4.5 of Appendix 5B (No Interference) hereto, and
shall address without limitation DNS services; operation of the shared
registration system; RDDS; and nameserver operations. Registry Operator shall
keep technical and operational records sufficient to evidence compliance with
such specifications for at least one year.
(iii) Registry
Services. Registry Services are, for purposes of this Agreement, defined as
the following: (a) those services that are both (i) 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 zone servers; and dissemination of
contact and other information concerning domain name server registrations in
the TLD as required by this Agreement; and (ii) provided by the Registry
Operator for the .com registry as of March 31, 2006, as the case may be; (b)
other products or services that the Registry Operator is required to provide
because of the establishment of a Consensus Policy (as defined in Section
3.1(b) above); (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. Only Registry Services defined in (a) and (b) above are subject
to the maximum price provisions of Section 7.3, below.
(iv) Process
for Consideration of Proposed Registry Services. Following written
notification by Registry Operator to ICANN that Registry Operator may make a
change in a Registry Service within the scope of the preceding paragraph:
(A) ICANN shall
have 15 calendar days to make a "preliminary determination" whether a
Registry Service requires further consideration by ICANN because it reasonably
determines such Registry Service: (i) could raise significant Security or Stability
issues or (ii) could raise significant competition issues.
(B) Registry
Operator must provide sufficient information at the time of notification to ICANN
that it may implement such a proposed Registry Service to enable ICANN to make
an informed "preliminary determination." Information provided by
Registry Operator and marked "CONFIDENTIAL" shall be treated as
confidential by ICANN. Registry Operator will not designate
"CONFIDENTIAL" information necessary to describe the purpose of the
proposed Registry Service and the effect on users of the DNS.
(C) ICANN may seek
expert advice during the preliminary determination period (from entities or
persons subject to confidentiality agreements) on the competition, Security or Stability
implications of the Registry Service in order to make its "preliminary
determination." To the extent ICANN determines to disclose confidential
information to any such experts, it will provide notice to Registry Operator of
the identity of the expert(s) and the information it intends to convey.
(D) If ICANN determines
during the 15 calendar day "preliminary determination" period that
the proposed Registry Service, does not raise significant Security or Stability
(as defined below), or competition issues, Registry Operator shall be free to
deploy it upon such a determination.
(E) In the event ICANN
reasonably determines during the 15 calendar day "preliminary
determination" period that the Registry Service might raise significant
competition issues, ICANN shall refer the issue to the appropriate governmental
competition authority or authorities with jurisdiction over the matter within
five business days of making its determination, or two business days following
the expiration of such 15 day period, whichever is earlier, with notice to
Registry Operator. Any such referral communication shall be posted on ICANN's
website on the date of transmittal. Following such referral, ICANN shall have
no further responsibility, and Registry Operator shall have no further
obligation to ICANN, with respect to any competition issues relating to the
Registry Service. If such a referral occurs, the Registry Operator will not
deploy the Registry Service until 45 calendar days following the referral,
unless earlier cleared by the referred governmental competition authority.
(F) In the event
that ICANN reasonably determines during the 15 calendar day "preliminary
determination" period that the proposed Registry Service might raise
significant Stability or Security issues (as defined below), ICANN will refer
the proposal to a Standing Panel of experts (as defined below) within five
business days of making its determination, or two business days following the
expiration of such 15 day period, whichever is earlier, and simultaneously
invite public comment on the proposal. The Standing Panel shall have 45
calendar days from the referral to prepare a written report regarding the
proposed Registry Service's effect on Security or Stability (as defined below),
which report (along with a summary of any public comments) shall be forwarded
to the ICANN Board. The report shall set forward the opinions of the Standing
Panel, including, but not limited to, a detailed statement of the analysis,
reasons, and information upon which the panel has relied in reaching their
conclusions, along with the response to any specific questions that were
included in the referral from ICANN staff. Upon ICANN's referral to the
Standing Panel, Registry Operator may submit additional information or analyses
regarding the likely effect on Security or Stability of the Registry Service.
(G) Upon its
evaluation of the proposed Registry Service, the Standing Panel will report on
the likelihood and materiality of the proposed Registry Service's effects on Security
or Stability, including whether the proposed Registry Service creates a
reasonable risk of a meaningful adverse effect on Security or Stability as
defined below:
Security: For purposes of this Agreement,
an effect on security by the proposed Registry Service 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.
Stability: For purposes of
this Agreement, an effect on stability shall mean that the proposed Registry
Service (1) is not compliant with applicable relevant standards that are
authoritative and published by a well-established, recognized and authoritative
standards body, such as relevant Standards-Track or Best Current Practice RFCs
sponsored by the IETF or (2) creates 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,
recognized and authoritative standards body, such as relevant Standards-Track
or Best Current Practice RFCs and relying on Registry Operator's delegation
information or provisioning services.
(H) Following
receipt of the Standing Panel's report, which will be posted (with appropriate
confidentiality redactions made after consultation with Registry Operator) and
available for public comment, the ICANN Board will have 30 calendar days to
reach a decision. In the event the ICANN Board reasonably determines that the
proposed Registry Service creates a reasonable risk of a meaningful adverse
effect on Stability or Security, Registry Operator will not offer the proposed
Registry Service. An unredacted version of the Standing Panel's report shall be
provided to Registry Operator upon the posting of the report. The Registry Operator
may respond to the report of the Standing Panel or otherwise submit to the ICANN
Board additional information or analyses regarding the likely effect on Security
or Stability of the Registry Service.
(I) The Standing
Panel shall consist of a total of 20 persons expert in the design, management
and implementation of the complex systems and standards-protocols utilized in
the Internet infrastructure and DNS (the "Standing Panel"). The
members of the Standing Panel will be selected by its Chair. The Chair of the
Standing Panel will be a person who is agreeable to both ICANN and the registry
constituency of the supporting organization then responsible for generic top
level domain registry policies. All members of the Standing Panel and the Chair
shall execute an agreement requiring that they shall consider the issues before
the panel neutrally and according to the definitions of Security and Stability.
For each matter referred to the Standing Panel, the Chair shall select no more
than five members from the Standing Panel to evaluate the referred matter, none
of which shall have an existing competitive, financial, or legal conflict of
interest, and with due regard to the particular technical issues raised by the
referral.
(e) Fees and
Payments. Registry Operator shall pay the
Registry-Level Fees to ICANN on a quarterly basis in accordance with Section
7.2 hereof.
(f) Traffic
Data. Nothing in this Agreement shall preclude Registry Operator from
making commercial use of, or collecting, traffic data regarding domain names or
non-existent domain names for purposes such as, without limitation, the
determination of the availability and Security and Stability of the Internet,
pinpointing specific points of failure, characterizing attacks and
misconfigurations, identifying compromised networks and hosts, and promoting
the sale of domain names; provided, however, that such use does not disclose
domain name registrant, end user information or other Personal Data as defined
in Section 3.1(c)(ii) for any purpose not otherwise authorized by this Agreement.
In this regard, in the event the TLD registry is a "thick" registry
model, the traffic data that may be accessible to and used by Registry Operator
shall be limited to the data that would be accessible to a registry operated
under a "thin" registry model. The process for the introduction of
new Registry Services shall not apply to such traffic data. Nothing contained
in this Section 3.1(f) shall be deemed to constitute consent or acquiescence by
ICANN to a re-introduction by Registry Operator of the SiteFinder service
previously introduced by the Registry Operator on or about September 15, 2003,
or the introduction of any other service employing a universal wildcard
function, except that this sentence shall not prohibit the provision of
nameservice or any other non-registry service for a domain or zone used for
other than registration services to unaffiliated third parties by a single
entity (including its affiliates) for domain names registered through an ICANN-accredited
registrar. To the extent that traffic data subject to this provision is made
available, access shall be on terms that are non-discriminatory.
(g) Security and
Stability Review. Twice annually Registry Operator shall engage in
discussions with executive staff of ICANN and the Chairman of the Board of ICANN
on trends impacting the Security and/or Stability of the Registry, the DNS or
the Internet pursuant to the terms of confidentiality agreements executed both
by the executive staff of ICANN and the Chairman of the Board.
(h) Business Continuity. To preserve and
enhance the security, stability and resiliency of the TLD and the Internet,
Registry Operator and ICANN agree that internal subject matter experts in
critical registry functions, operations and security from both parties will
meet and discuss how: (i) the parties may
address business continuity under various scenarios, including appropriate
criteria for triggering any business continuity mechanisms; and (ii) to
mitigate risks to the TLD and Internet resulting from such business continuity
scenarios. Such discussions will be held every month at a time and place
mutually agreed to by the parties and shall occur over a period of at least 180
days following the Effective Date, unless the parties agree to a shorter
time frame in writing (which may be via email). Following completion of the
discussions described herein, the parties will use commercially reasonable
efforts to determine the implementation of any business continuity practices
that are reasonably appropriate for the TLD. The parties agree that such
implementation may include amendments to this Agreement mutually agreed upon by
the parties in writing.
Section 3.2 Covenants of ICANN. ICANN
covenants and agrees with Registry Operator as follows:
(a) Open and
Transparent. Consistent with ICANN's expressed mission and core values, ICANN
shall operate in an open and transparent manner.
(b) Equitable
Treatment. ICANN shall not apply standards, policies, procedures or
practices arbitrarily, unjustifiably, or inequitably and shall not single out
Registry Operator for disparate treatment unless justified by substantial and
reasonable cause.
(c) TLD Zone
Servers. In the event and to the extent that ICANN is authorized to set
policy with regard to an authoritative root server system, it will ensure that
(i) the authoritative root will point to the TLD zone servers designated by
Registry Operator for the Registry TLD throughout the Term of this Agreement;
and (ii) any changes to the TLD zone server designation submitted to ICANN by
Registry Operator will be implemented by ICANN within seven days of submission.
(d) Nameserver
Changes. Registry Operator may request changes in the nameserver delegation
for the Registry TLD. Any such request must be made in a format, and otherwise
meet technical requirements, specified from time to time by ICANN. ICANN will
use commercially reasonable efforts to have such requests implemented in the
Authoritative Root-Server System within seven calendar days of the submission.
(e) Root-zone
Information Publication. ICANN's publication of root-zone contact
information for the Registry 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.
Section 3.3 Cooperation.
The parties agree to cooperate with each other and share data as necessary to
accomplish the terms of this Agreement.
Section 3.4 Contractual
and Operational Compliance Audits.
(a) ICANN may from
time to time (not to exceed once per calendar quarter) conduct, or engage a
third party to conduct, contractual compliance audits to assess compliance by
Registry Operator with its representations and warranties contained in Article
II of this Agreement and its covenants contained in Article III of this
Agreement. Such audits shall be tailored to achieve the purpose of assessing
compliance, and ICANN will (i) give reasonable advance notice of any such
audit, which notice shall specify in reasonable detail the categories of
documents, data and other information requested by ICANN, and (ii) use
commercially reasonable efforts to conduct such audit in such a manner as to
not unreasonably disrupt the operations of Registry Operator. As part of such
audit and upon request by ICANN, Registry Operator shall timely provide all
responsive documents, data and any other information necessary to demonstrate
Registry Operator's compliance with this Agreement. Upon no less than five (5)
business 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 covenants
contained in Section 3.1.
(b) Any audit
conducted pursuant to Section 3.4(a) will be at ICANN's expense, unless (i) the
audit relates to Registry Operator's compliance with Section 3.1(c)(iv) and
such audit reveals a material discrepancy or discrepancies in the data provided
by Registry Operator, or (ii) the audit is related to a discrepancy in the fees
paid by Registry Operator hereunder in excess of 5% to ICANN's detriment. In
either such case of (i) or (ii) above, Registry Operator shall reimburse ICANN for
all reasonable costs and expenses associated with such audit and 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.
ARTICLE IV TERM OF AGREEMENT
Section 4.1 Term.
The term of this Agreement shall begin on the Effective Date and continue
through November 30, 2030 (“Initial Registry Agreement Term”), as extended by
any renewal terms pursuant to Section 4.2 (Renewal) (each a “Renewal Registry
Agreement Term”). Together the Initial Registry Agreement Term and all Renewal
Registry Agreement Terms shall constitute the (“Term”).
Section 4.2 Renewal. This Agreement
shall be renewed upon the expiration of the Initial Registry Agreement Term set
forth in Section 4.1 above and each Renewal Registry Agreement Term, unless the
following has occurred: (i) following notice of breach to Registry Operator in
accordance with Section 6.1 and failure to cure such breach within the time
period prescribed in Section 6.1, an arbitrator or court has determined that
Registry Operator has been in fundamental and material breach of Registry
Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section
5.2 or Section 7.3 and (ii) following the final decision of such arbitrator or
court, Registry Operator has failed to comply within ten days with the decision
of the arbitrator or court, or within such other time period as may be
prescribed by the arbitrator or court. Upon renewal, in the event that the
terms of this Agreement are not similar to the terms generally in effect in the
Registry Agreements of the 5 largest gTLDs (determined by the number of domain
name registrations under management at the time of renewal), renewal shall be
upon terms reasonably necessary to render the terms of this Agreement similar
to such terms in the Registry Agreements for those other gTLDs. The preceding sentence,
however, shall not apply to the terms of this Agreement regarding the price of
Registry Services; the standards for the consideration of proposed Registry
Services, including the definitions of Security and Stability and the standards
applied by ICANN in the consideration process; the terms or conditions for the
renewal or termination of this Agreement; ICANN's obligations to Registry
Operator under Section 3.2 (a), (b), and (c); the limitations on Consensus Policies
or Temporary Specifications or Policies; the definition of Registry Services;
or the terms of Section 7.3.
Section 4.3 Failure
to Perform in Good Faith. In the event Registry Operator shall have been
repeatedly and willfully in fundamental and material breach of Registry
Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section
5.2 or Section 7.3, and arbitrators in accordance with Section 5.1(b) of this
Agreement repeatedly have found Registry Operator to have been in fundamental
and material breach of this Agreement, including in at least three separate
awards, then the arbitrators shall award such punitive, exemplary or other
damages as they may believe appropriate under the circumstances.
ARTICLE V DISPUTE RESOLUTION
Section 5.1 Resolution
of Disputes.
(a) Cooperative
Engagement. In the event of a disagreement between Registry Operator and ICANN
arising under or out of this Agreement, either party may by notice to the other
invoke the dispute resolution provisions of this Article V. Provided, however,
that before either party may initiate arbitration as provided in Section 5.1(b)
below, ICANN and Registry Operator must attempt to resolve the dispute by
cooperative engagement as set forth in this Section 5.1(a). If either party
provides written notice to the other demanding cooperative engagement as set
forth in this Section 5.1(a), then each party will, within seven calendar days
after such written notice is deemed received in accordance with Section 8.8
hereof, designate a single executive officer as its representative under this
Section 5.1(a) with full authority to act on such party's behalf to resolve the
dispute. The designated representatives shall, within 2 business days after
being designated, confer by telephone or in person to attempt to resolve the
dispute. If they are not able to resolve the dispute during such telephone
conference or meeting, they shall further meet in person at a location
reasonably designated by ICANN within 7 calendar days after such initial
telephone conference or meeting, at which meeting the parties shall attempt to
reach a definitive resolution. The time schedule and process set forth in this
Section 5.1(a) may be modified with respect to any dispute, but only if both parties
agree to a revised time schedule or process in writing in advance. Settlement
communications within the scope of this paragraph shall be inadmissible in any
arbitration or litigation between the parties.
(b) Arbitration.
Disputes arising under or in connection with this Agreement, including requests
for specific performance, shall be resolved through binding arbitration
conducted as provided in this Section 5.1(b) pursuant to the rules of the
International Court of Arbitration of the International Chamber of Commerce
("ICC"). The arbitration shall be conducted in the English language
and shall occur in Los Angeles County, California, USA only following the
failure to resolve the dispute pursuant to cooperative engagement discussions
as set forth in Section 5.1(a) above. There shall be three arbitrators: each
party shall choose one arbitrator and, if the two arbitrators are not able to
agree on a third arbitrator, the third shall be chosen by the ICC. The
prevailing party in the arbitration shall have the right to recover its costs
and reasonable attorneys' fees, which the arbitrators shall include in their
awards. Any party that seeks to confirm or vacate an arbitration award issued
under this Section 5.1(b) may do so only pursuant to the applicable arbitration
statutes. In any litigation involving ICANN concerning this Agreement,
jurisdiction and exclusive venue for such litigation shall be in a court
located in Los Angeles County, California, USA; however, the parties shall also
have the right to enforce a judgment of such a court in any court of competent
jurisdiction. For the purpose of aiding the arbitration and/or preserving the
rights of the parties during the pendency of an arbitration, the parties shall
have the right to seek a temporary stay or injunctive relief from the
arbitration panel or a court, which shall not be a waiver of this agreement to
arbitrate.
Section 5.2 Specific
Performance. Registry Operator and ICANN agree that irreparable damage
could occur if any of the provisions of this Agreement was not performed in
accordance with its specific terms. Accordingly, the parties agree that they
each shall be entitled to seek from the arbitrators specific performance of the
terms of this Agreement (in addition to any other remedy to which each party is
entitled).
Section 5.3 Limitation
of Liability. ICANN's aggregate monetary liability
for violations of this Agreement shall not exceed an amount equal to the
Registry-Level Fees paid by Registry Operator to ICANN within the preceding
twelve-month period pursuant to Section 7.2 of this Agreement. Registry
Operator's aggregate monetary liability to ICANN for violations of this
Agreement shall be limited to an amount equal to the fees and monetary
sanctions, if any, due and owing to ICANN under this Agreement within the preceding
twelve month period. In no event shall either party be liable for special,
indirect, incidental, punitive, exemplary, or consequential damages arising out
of or in connection with this Agreement or the performance or nonperformance of
obligations undertaken in this Agreement, except as provided pursuant to
Section 4.3 of this Agreement. EXCEPT AS OTHERWISE EXPRESSLY PROVIDED IN THIS
AGREEMENT, REGISTRY OPERATOR DOES NOT MAKE ANY WARRANTY, EXPRESS OR IMPLIED,
WITH RESPECT TO THE SERVICES RENDERED BY ITSELF, ITS SERVANTS, OR ITS AGENTS OR
THE RESULTS OBTAINED FROM THEIR WORK, INCLUDING, WITHOUT LIMITATION, ANY
IMPLIED WARRANTY OF MERCHANTABILITY, NON-INFRINGEMENT, OR FITNESS FOR A
PARTICULAR PURPOSE.
ARTICLE
VI TERMINATION PROVISIONS
Section 6.1 Termination
by ICANN. ICANN may terminate this Agreement if and only if: (i) Registry
Operator fails to cure any fundamental and material breach of Registry
Operator's obligations set forth in Sections 3.1(a), (b), (d) or (e); Section
5.2 or Section 7.3 within thirty calendar days after ICANN gives Registry
Operator written notice of the breach, which notice shall include with
specificity the details of the alleged breach; and (ii) (a) an arbitrator or
court has finally determined that Registry Operator is, or was, in fundamental
and material breach and failed to cure such breach within the prescribed time
period and (b) following the decision of such arbitrator or court, Registry
Operator has failed to comply with the decision of the arbitrator or court.
Section 6.2 Bankruptcy.
This Agreement shall automatically terminate in the event Registry Operator
shall voluntarily or involuntarily be subject to bankruptcy proceedings.
Section 6.3 Transition
of Registry upon Termination of Agreement. Upon any termination of this
Agreement as provided in Sections 6.1 and 6.2, the parties agree to work
cooperatively to facilitate and implement the transition of the registry for
the TLD in accordance with this Section 6.3. Registry Operator shall agree to
provide ICANN or any successor registry authority that may be designated for
the TLD with any data regarding operations of the registry for the TLD necessary
to maintain operations that may be reasonably requested in addition to that
data escrowed in accordance with Section 3.1(c)(i) hereof.
Section 6.4 Rights
in Data. Registry Operator shall not be entitled to claim any intellectual
property rights in Registry Data. In the event that Registry Data is released
from escrow as set forth in Section 3.1(c)(i), rights, if any, held by Registry
Operator in the data shall automatically be licensed on a non-exclusive,
irrevocable, royalty-free, paid-up basis to ICANN or to a party designated in
writing by ICANN.
Section 6.5 No
Reimbursement. Any and all expenditures, capital investments or other
investments made by Registry Operator in connection with this Agreement shall
be at Registry Operator's own risk and ICANN shall have no obligation to
reimburse Registry Operator for any such expense, capital expenditure or
investment. Registry Operator shall not be required to make any payments to a
successor registry operator by reason of registry fees paid to Registry Operator
prior to the effective date of (i) any termination or expiration of this
Agreement or (ii) transition of the registry, unless any delay in transition of
the registry to a successor operator shall be due to the actions of Registry
Operator.
ARTICLE VII SPECIAL PROVISIONS
Section
7.1 Registry-Registrar Agreement.
(a)
Access to Registry Services. Registry Operator shall make access to
Registry Services, including the shared registration system, available to all ICANN-accredited
registrars, subject to the terms of the Registry-Registrar Agreement attached
as Appendix 8 hereto. Subject to Section 7.1(d), Registry Operator shall
provide all ICANN-accredited registrars following execution of the
Registry-Registrar Agreement, provided registrars are in compliance with such
agreement, operational access to Registry Services, including the shared
registration system for the TLD. Such nondiscriminatory access shall include
without limitation the following:
(i) All registrars
(including any registrar affiliated with Registry Operator, if any) can connect
to the shared registration system gateway for the TLD via the Internet by
utilizing the same maximum number of IP addresses and SSL certificate
authentication;
(ii) Registry
Operator has made the current version of the registrar toolkit software
accessible to all registrars and has made any updates available to all
registrars on the same schedule;
(iii) All
registrars have the same level of access to customer support personnel via
telephone, e-mail and Registry Operator's website;
(iv) All
registrars have the same level of access to registry resources to resolve
registry/registrar or registrar/registrar disputes and technical and/or
administrative customer service issues;
(v) All registrars
have the same level of access to data generated by Registry Operator to
reconcile their registration activities from Registry Operator's Web and ftp
servers;
(vi) All
registrars may perform basic automated registrar account management functions
using the same registrar tool made available to all registrars by Registry
Operator; and
(vii) The shared
registration system does not include, for purposes of providing discriminatory
access, any algorithms or protocols that differentiate among registrars with
respect to functionality, including database access, system priorities and
overall performance.
Such Registry-Registrar Agreement may be
revised by Registry Operator from time to time, provided however, that any such
revisions must be approved in advance by ICANN.
(b) Registry
Operator Shall Not Act as Own Registrar. Registry Operator shall not act as
a registrar with respect to the TLD. This shall not preclude Registry Operator
from registering names within the TLD to itself through a request made to an ICANN-accredited
registrar. In addition, where there is an imminent threat to the Security and Stability
of the TLD or the Internet, this provision shall not preclude Registry
Operator, for the purpose of protecting the Security and Stability of the TLD or
the Internet, from temporarily preventing the registration of one or more
names; provided, as soon as practicable but no later than 3 business days of
taking such action, Registry Operator provides ICANN with a written notice of
such action, which notice shall list all affected names, state the expected
length of time that such names will not be available for registration, and
explain why Registry Operator took such action. The contents of such notice
shall be treated as confidential to the extent permitted by law. If ICANN disagrees
with such action, it will instruct Registry Operator to release such names and
Registry Operator shall immediately release such names upon receipt of such
written instructions from ICANN.
(c) Restrictions
on Acquisition of Ownership or Controlling Interest in Registrar. Registry
Operator shall not acquire, directly or indirectly, control of, or a greater
than fifteen percent ownership interest in, any ICANN-accredited registrar for
the TLD.
(d) Compliance
Actions. Registry Operator acknowledges that all ICANN-accredited
registrars must enter into a registrar accreditation agreement
("RAA") with ICANN and ICANN may take certain compliance actions in
response to an emergency or in accordance with the terms of the RAA, including
suspension or termination of a registrar's accreditation or suspension of a
registrar's ability to create new registered names or initiate inbound
transfers of registered names. ICANN may require Registry Operator to take
specific actions consistent with ICANN's authority under the terms of the RAA to:
(i) suspend or terminate a registrar's ability to create new registered names
or (ii) transfer registered names to a registrar designated by ICANN.
Section 7.2 Fees to be Paid to
ICANN.
(a) Registry-Level
Fees. Registry Operator shall pay ICANN a registry-level fee equal to (i)
the “Registry Fixed Fee” of US$6,250 per calendar quarter by the 20th day
following the end of each calendar quarter (i.e., on January 20, April 20, July
20, and October 20), (ii) the Registry-Level Transaction Fee (as defined
below), (iii) the Sync Transaction Fee (as defined below) and (iv) the Variable
Registry-Level Fee (as defined in Section 7.2(b) below) (collectively
subclauses (i)-(iv), the “Registry-Level Fees”). Registry Operator shall
pay ICANN a “Registry-Level Transaction Fee” 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), during the applicable calendar quarter
multiplied by US$0.25. Registry Operator shall pay the Registry-Level
Transaction Fee by the 20th day following the end of each calendar quarter
(i.e., January 20, April 20, July 20, and October 20 for the calendar quarters
ending December 31, March 31, June 30, and September 30) of the year to an account
designated by ICANN. For each domain name registration in the TLD for which a
registrar extends the registration term pursuant to the Registry Operator’s
Consolidate/Sync Service (“Sync Service”) (referenced in Appendix 9 (Approved
Services)) on or after the Effective Date, Registry Operator shall pay ICANN an
additional fee, prorated from the amount of US$0.25, based on the number of
days the domain name registration is extended past its expiry date through the
Sync Service (“Sync Transaction Fee”). Registry Operator shall pay ICANN the
Sync Transaction Fee by the 20th calendar day following the end of the calendar
quarter in which the Sync Services occurred (i.e., January 20, April 20, July
20, and October 20).
(b) Variable
Registry-Level Fee. For fiscal quarters in which ICANN does not collect a
variable accreditation fee from all registrars, upon receipt of written notice
from ICANN, Registry Operator shall pay ICANN a Variable Registry-Level Fee (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 (July
1-September 30) 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 will invoice and collect the fees from the
registrars who are party to a Registry-Registrar Agreement with Registry
Operator. The Variable Registry-Level Fee will consist of two components; each
component will be calculated by ICANN for each registrar:
(i)The
transactional component of the Variable Registry-Level Fee shall be specified
by ICANN in accordance with the budget adopted by the ICANN Board of Directors
for each ICANN fiscal year but shall not exceed US$0.25.
(ii)The
per-registrar component of the Variable Registry-Level Fee shall be specified
by ICANN in accordance with the budget adopted by the ICANN Board of Directors
for each ICANN fiscal year.
(c) Interest on
Late Payments. For any payments ten days or more overdue pursuant to
Section 7.2, Registry Operator shall pay interest on late payments at the rate
of 1.5% per month or, if less, the maximum rate permitted by applicable law.
(d) Adjustments
to Fees. Notwithstanding
any of the fee limitations on the amount of Registry-Level Fees to be paid by
Registry Operator to ICANN under Section 7.2(a) or 7.2(b) of this Agreement,
commencing upon December 1st of each year during the Term, the then-current
fees set forth in Section 7.2(a) and Section 7.2(b) 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 7.2(d) 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.
(e) Fee Adjustment Practice. ICANN
agrees that if it exercises its right under Section 7.2(d) to adjust
Registry-Level Fees, ICANN shall also exercise its right under multiple other
registry agreements in a manner that does not single out Registry Operator.
(f) ICANN and Registry Operator hereby
agree that if ICANN delivers notice of a fee adjustment to other registry
operators after November 1, 2024 and prior to the Effective Date, ICANN may concurrently
deliver such fee adjustment notice to Registry Operator, in which case the
provisions of Section 7.2(d) shall be deemed to have applied at the time such
notice was sent.
Section 7.3 Pricing
for Domain Name Registrations and Registry Services.
(a) Scope.
The Registry Services to which the provisions of this Section 7.3 shall apply
are:
(i) the Registry
Services defined in Section 3.1(d)(iii)(a), above, and
(ii) other
products or services that the Registry Operator is required to provide within
the scope of Section 3.1(d)(iii)(b), above, because of the establishment of a Consensus
Policy (as defined in Section 3.1(b) above):
(1) to implement
changes in the core functional or performance specifications for Registry
Services (as defined in Section 3.1(d)(iii)(a)); or
(2) that are
reasonably necessary to facilitate: (A) Security and/or Stability of the
Internet or DNS; (B) Security and Stability of the registry database for the TLD;
or (C) resolution of disputes regarding the registration of domain names (as
opposed to the use of such domain names).
Nothing contained herein shall be
construed to apply the provisions of this Section 7.3 to the services
enumerated in Appendix 9 of this Agreement.
(b) No Tying.
Registry Operator shall not require, as a condition of the provision or use of
Registry Services subject to this Section 7.3 in accordance with the
requirements of this Agreement, including without limitation Section 7.1 and
Appendix 10, that the purchaser of such services purchase any other product or
service or refrain from purchasing any other product or service.
Notwithstanding any other offering that may include all or any portion of the
Registry Services at any price, Registry Operator shall offer to all ICANN-accredited
registrars the combination of all Registry Services subject to this Section 7.3
at a total price for those Registry Services that is no greater than the
Maximum Price calculated pursuant to Section 7.3(d) and that otherwise complies
with all the requirements of Section 7.3.
(c) Price for
Registry Services. The price for all Registry Services subject to this
Section 7.3 shall be the amount, not to exceed the Maximum Price, that Registry
Operator charges for each annual increment of a new and renewal domain name
registration and for each transfer of a domain name registration from one ICANN-accredited
registrar to another.
(d) Maximum
Price. The Maximum Price for Registry Services subject to this Section 7.3
shall be as follows:
(i) Subject to increase pursuant to
Section 7.3(d)(ii) and Section 7.3(d)(iii), the Maximum Price for Registry
Services shall be US $10.26;
(ii) Registry Operator is entitled to
increase the Maximum Price by the smaller of (A) the Maximum Price for the
preceding Pricing Year (as defined in Section 7.3(d)(iii) below), multiplied by
1.07, or (B) the highest price charged by Registry Operator for Registry
Services during the preceding Pricing Year, multiplied by 1.07, and in the case
of (A) or (B), in each Pricing Year of the final four Pricing Years of every
six year period, with the first six year period beginning on October 26, 2018;
and
(iii) Registry Operator is entitled to
increase the Maximum Price by an amount sufficient to cover any additional
incremental costs incurred, or to be incurred, by Registry Operator due to the
imposition of any new Consensus Policy or documented extraordinary expense
resulting from an attack or threat of attack on the Security or Stability of
the DNS (“Consensus Policy or Documented Extraordinary Expense”) in each
Pricing Year by an amount not to exceed the smaller of (A) the Maximum Price
for the preceding Pricing Year, multiplied by 1.07, or (B) the highest price
charged by Registry Operator for Registry Services during the preceding Pricing
Year, multiplied by 1.07, provided that, Registry Operator may only increase
the Maximum Price for a Consensus Policy or Documented Extraordinary Expense
pursuant to this Section 7.3(d)(iii) in a Pricing Year where Registry Operator
has not, and will not, increase the Maximum Price for Registry Services
pursuant to Section 7.3(d)(ii) above. For purposes of Section 7.3, “Pricing
Year” shall mean the period from October 26 to October 25.
(e) No price
discrimination. Registry Operator shall charge the same price for Registry
Services subject to this Section 7.3, not to exceed the Maximum Price, to all ICANN-accredited
registrars (provided that volume discounts and marketing support and incentive
programs may be made if the same opportunities to qualify for those discounts
and marketing support and incentive programs is available to all ICANN-accredited
registrars).
(f) Adjustments
to Pricing for Domain Name Registrations. Registry Operator shall provide
no less than six months prior notice in advance of any increase for new and
renewal domain name registrations and for transferring a domain name
registration from one ICANN-accredited registrar to another and shall continue
to offer for periods of up to ten years new and renewal domain name
registrations fixed at the price in effect at the time such offer is accepted.
Registry Operator is not required to give notice of the imposition of the
Variable Registry-Level Fee set forth in Section 7.2(b).
(g) Maximum
Price does not include ICANN Variable Registry-Level Fee. The Maximum Price
does not include, and shall not be calculated from a price that includes, all
or any part of the ICANN Variable Registry-Level Fee set forth in Section
7.2(b), above, or any other per-name fee for new and renewal domain name
registrations and for transferring a domain name registration from one ICANN-accredited
registrar to another.
ARTICLE VIII MISCELLANEOUS
Section 8.1 Indemnification
of ICANN.
(a) Registry
Operator shall indemnify, defend, and hold harmless ICANN (including its
directors, officers, employees, and agents) 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: (a) ICANN's
reliance, in connection with its decision to delegate the TLD to Registry
Operator or to enter into this Agreement, on information provided by Registry
Operator in its application for the TLD; (b) Registry Operator's establishment
or operation of the registry for the TLD; (c) Registry Operator's provision of
Registry Services; (d) collection or handling of Personal Data by Registry
Operator; (e) any dispute concerning registration of a domain name within the
domain of the TLD for the registry; and (f) duties and obligations of Registry
Operator in operating the registry for the TLD; provided that Registry Operator
shall not be obligated to indemnify, defend, or hold harmless ICANN to the
extent the claim, damage, liability, cost, or expense arose due to a breach by ICANN
of any obligation contained in this Agreement or any willful misconduct of ICANN.
For avoidance of doubt, nothing in this Section 8.1 shall be deemed to require
Registry Operator to reimburse or otherwise indemnify ICANN for the costs
associated with the negotiation or execution of this Agreement, or with the
monitoring or management of the parties' respective obligations under this
Agreement. 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.
(b) For any claims
by ICANN for indemnification whereby multiple registry operators (including
Registry Operator) have engaged in the 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 Section 7.2 hereof for any applicable quarter) by
the total number of domain names under registration within all TLDs for which
the registry operators thereof that are engaging in the same acts or omissions
giving rise to such claim. 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 above, but such registry operator(s) do not have the same or similar indemnification
obligations to ICANN at set forth in 8.1(a) above, the number of domains under
management by such registry operator(s) shall nonetheless be included in the
calculation in the preceding sentence.
Section 8.2 Indemnification
Procedures. If ICANN receives notice of any third-party claim that is
indemnified under Section 8.1 above, ICANN shall promptly notify Registry
Operator of such claim. Registry Operator shall be entitled, if it so elects,
in a notice promptly delivered to ICANN, to immediately take control of the
defense and investigation of such claim and to employ and engage attorneys
reasonably acceptable to the indemnified party to handle and defend the same,
at the indemnifying party's sole cost and expense, provided that in all events ICANN
shall be entitled to control at its sole cost and expense the litigation of
issues concerning the validity or interpretation of ICANN policies or conduct. ICANN
shall cooperate, at its own cost, in all reasonable respects with Registry
Operator and its attorneys in the investigation, trial, and defense of such
claim and any appeal arising therefrom; provided, however, that the indemnified
party may, at its own cost and expense, participate, through its attorneys or
otherwise, in such investigation, trial and defense of such claim and any
appeal arising therefrom. No settlement of a claim that involves a remedy
affecting ICANN other than the payment of money in an amount that is
indemnified shall be entered into without the consent of ICANN. If Registry
Operator does not assume full control over the defense of a claim subject to
such defense in accordance with this Section, Registry Operator may participate
in such defense, at its sole cost and expense, and ICANN shall have the right
to defend the claim in such manner as it may deem appropriate, at the cost and
expense of Registry Operator.
Section 8.3 No
Offset. All payments due under this Agreement shall be made in a timely
manner throughout the Term of this Agreement and notwithstanding the pendency
of any dispute (monetary or otherwise) between Registry Operator and ICANN.
Section 8.4 Use
of ICANN Name and Logo. ICANN grants to Registry Operator a non-exclusive
royalty-free license to state that it is designated by ICANN as the Registry
Operator for the Registry TLD and to use a logo specified by ICANN to signify
that Registry Operator is an ICANN-designated registry authority. This license
may not be assigned or sublicensed by Registry Operator.
Section 8.5 Assignment
and Subcontracting. Any assignment of this Agreement shall be effective
only upon written agreement by the assignee with the other party to assume the
assigning party's obligations under this Agreement. Moreover, neither party may
assign this Agreement without the prior written approval of the other party,
which shall not be unreasonably withheld. Notwithstanding the foregoing, ICANN may
assign this Agreement in conjunction with a reorganization or re-incorporation
of ICANN, to another nonprofit corporation organized for the same or
substantially the same purposes. Registry Operator must provide notice to ICANN
of any subcontracting arrangements, and any agreement to subcontract portions
of the operations of the TLD must mandate compliance with all covenants,
obligations and agreements by Registry Operator hereunder. Any subcontracting
of technical operations shall provide that the subcontracted entity become
party to the data escrow agreement mandated by Section 3.1(c)(i) hereof.
Section 8.6 Amendments
and Waivers. No amendment, supplement, or modification of this Agreement or
any provision hereof shall be binding unless executed in writing by both
parties. No waiver of any provision of this Agreement shall be binding unless
evidenced by a writing signed by the party waiving compliance with such
provision. No waiver of any of the provisions of this Agreement or failure to
enforce any of the provisions hereof shall be deemed or shall constitute a
waiver of any other provision hereof, nor shall any such waiver constitute a
continuing waiver unless otherwise expressly provided.
Section 8.7 No
Third-Party Beneficiaries. This Agreement shall not be construed to create
any obligation by either ICANN or Registry Operator to any non-party to this
Agreement, including any registrar or registered name holder.
Section 8.8 Notices,
Designations, and Specifications. All notices to be given under or in
relation to this Agreement shall be given either (i) in writing at the address
of the appropriate party as set forth below or (ii) via electronic mail as
provided below, unless that party has given a notice of change of postal or
email address, as provided in this Agreement. Any change in the contact
information for notice below shall be given by the party within 30 days of such
change. Any notice required by this Agreement shall be deemed to have been
properly given (i) if in paper form, when delivered in person or via courier
service with confirmation of receipt or (ii) by electronic mail, upon
confirmation of receipt by the recipient's email server. Whenever this Agreement
shall specify a URL address for certain information, Registry Operator shall be
deemed to have been given notice of any such information when electronically
posted at the designated URL. In the event other means of notice shall become
practically achievable, such as notice via a secure website, the parties shall
work together to implement such notice means under this Agreement.
If to ICANN, addressed to:
Internet Corporation for Assigned Names
and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
Telephone: 1-310-301-5800
Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
If to Registry Operator, addressed to:
VeriSign, Inc.
12061 Bluemont Way,
Reston, Virginia 20190
Telephone: 1-703-948-3200
Attention: SVP, Deputy General Counsel
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
Section 8.9 Language;
Calendar Days. Notices, designations, determinations, and specifications
made under this Agreement shall be in the English language. Notwithstanding
anything to the contrary, unless specified as “business days,” the word “days”
used in this Agreement shall mean “calendar days.”
Section 8.10 Counterparts.
This Agreement may be executed in one or more counterparts, each of which shall
be deemed an original, but all of which together shall constitute one and the
same instrument.
Section 8.11 Entire
Agreement. Upon execution, this Agreement amends and restates the Prior
Agreement in its entirety. This Agreement (including its Appendices, which
form a part of it) constitutes the entire agreement of the parties hereto
pertaining to the operation of the TLD and supersedes all prior agreements,
understandings, negotiations and discussions, whether oral or written, between
the parties on that subject. In the event of a conflict between the provisions
in the body of this Agreement and any provision in its Appendices, the
provisions in the body of the Agreement shall control.
[signature page
follows]
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:_____________________________
Sally Costerton
Interim President and Chief Executive Officer
Date:
VeriSign, Inc.
By:_____________________________
D. James Bidzos
Executive Chairman, President and Chief Executive Officer
Date:
.com
Registry Agreement Appendix 1
Data
Escrow Specification
Registry Operator
will engage an independent entity to act as data escrow agent (the “Escrow
Agent”) for the provision of data escrow services related to the Agreement
pursuant to an agreement substantially in the form of Appendix 2, as the same
may be revised from time to time, among ICANN, Registry Operator and the Escrow
Agent.
Changes to the
schedule, content, format, and procedure set forth herein may be made only with
the mutual written consent of ICANN and Registry Operator (which neither party
shall unreasonably withhold) or through the establishment of a Consensus Policy
as outlined in Section 3.1(b) of the Agreement.
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 in the registry through 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 including data through 00:00:00 UTC of each day, but
Monday. Differential Deposits must include complete escrow records as specified
below that were not included or changed since the most recent Full or
Differential Deposit (i.e., all additions, modifications or removals of data
since the last deposit).
2
Schedule
for Deposits.
Registry Operator will submit a set of escrow files on a daily basis as follows:
2.1
Each
Monday, 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 RFC 8909, see Section 9, reference 1 of this
Appendix and RFC 9022, see Section 9, reference 2 of this Appendix
(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. UTF-8 character encoding will be used.
3.2
Extensions. If 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 Section 9, reference 2 of this
Appendix. Data related to the “extensions
schemas” will be included in the deposit file described in Section 3.1 of this
Appendix. ICANN and 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 Section 9, reference 3 of this Appendix. 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 Section 9, reference 4 of this Appendix, 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 Section 9, reference 1 of this Appendix
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
Section 8 of this Appendix.
5.
File
Naming Conventions. Files will be named according to the following
convention: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:
5.1
{gTLD}
is replaced with the gTLD name; in case of an IDN-TLD, the ASCII- compatible form (A-Label) must be used;
5.2
{YYYY-MM-DD}
is replaced by the date corresponding to the time used as a timeline watermark
for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the string to be
used would be “2009-08-02”;
5.3
{type}
is replaced by:
1)
“full”,
if the data represents a Full Deposit;
2)
“diff”,
if the data represents a Differential Deposit;
3)
“thin”,
if the data represents a Bulk Registration Data Access file, as specified in Section 5.1 of Appendix
5A;
4)
"thick-{gurid}",
if the data represents Registration Data from a specific registrar, as defined
in Section 5.2 of Appendix 5A. The {gurid} element must be replaced with the
IANA Registrar ID associated with the data.
5.4
{#}
is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone file, this must be
replaced by “1”;
5.5
{rev}
is replaced by the number of revision (or resend) of the file beginning with “0”: and
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 Section 9, reference 5 of this Appendix (the
“Interface Specification”)) a written statement from Registry Operator (which
may be by authenticated e-mail) that includes a copy of the report generated
upon creation of the Deposit and states that the Deposit has been inspected by
Registry Operator and is complete and accurate. The preparation and submission
of this statement must be performed by Registry Operator or its designee,
provided that such designee may not be the Escrow Agent or any of Escrow
Agent’s affiliates. Registry Operator will include the Deposit’s “id” and
“resend” attributes in its statement. The attributes are explained in Section
9, reference 1 of this Appendix.
If not already an
RFC, Registry Operator will use the most recent draft version of the Interface
Specification as of December 1, 2024. Registry Operator may at its election use
newer versions of the Interface Specification after December 1, 2024. Once the
Interface Specification is published as an RFC, Registry Operator will
implement that version of the Interface Specification, no later than one
hundred eighty (180) calendar days after such publishing.
8. Verification Procedure.
1)
The
signature file of each processed file is validated.
2)
If
processed files are pieces of a bigger file, the latter is put together.
3)
Each
file obtained in the previous step is then decrypted and uncompressed.
4)
Each
data file contained in the previous step is then validated against the format
defined in Section 9, reference 1 of this Appendix.
5)
The
data escrow agent extended verification process, as defined below in Section 9,
reference 2 of this Appendix, as well as any other data escrow verification
process contained in such reference.
If any discrepancy
is found in any of the steps, the Deposit will be considered incomplete.
9. References.
1)
Registry
Data Escrow Specification, https://www.rfc-editor.org/rfc/rfc8909.txt
2)
Domain
Name Registration Data (DNRD) Objects Mapping, https://www.rfc-editor.org/rfc/rfc9022.txt
3)
OpenPGP
Message Format, https://www.rfc-editor.org/rfc/rfc4880.txt
4)
OpenPGP
parameters, https://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml
5)
ICANN
interfaces for registries and data escrow agents, https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces
.com Registry Agreement Appendix 2
Escrow Agreement (Template Format)
This Escrow
Agreement ("Escrow Agreement") is made as of [ ] (“Effective Date”),
by and between VeriSign, Inc. ("Registry
Operator"), [ ]("Escrow Agent"), and the Internet
Corporation for Assigned Names and Numbers ("ICANN").
Preliminary Statement. Registry Operator intends
to deliver the "Deposits” to Escrow Agent as
defined and provided for herein. Registry Operator desires Escrow Agent to hold
the Deposits and, upon certain events described herein, deliver the Deposits
(or a copy thereof) to ICANN in accordance with the terms hereof.
Now, therefore, in consideration of the foregoing, of the mutual
promises hereinafter set forth,
and for other good and valuable consideration, the receipt and sufficiency of which are hereby
acknowledged, the parties agree as follows:
1. Delivery
by Registry Operator. Registry
Operator shall be solely responsible for delivering to Escrow Agent the
Deposits, as defined and described in the "Data Escrow
Specification," attached as Appendix 1A or Appendix 1, as applicable, to
the .com Registry Agreement between Registry Operator and ICANN (the "Registry Agreement") and incorporated herein by this reference ("Appendix 1A" or “Appendix 1,” as applicable). Registry Operator may
elect to deliver the Deposits to Escrow Agent in accordance with Appendix 1A or
Appendix 1, as applicable, or in a manner mutually agreed upon by Escrow Agent
and Registry Operator. Upon receipt of the Deposits, Escrow Agent shall
immediately process the Deposits in accordance with Appendix 1A or Appendix 1,
as applicable, and generate a file listing, which Escrow Agent shall, within
ten (10) business days of the end of each calendar
month, forward to Registry Operator, via email or United States mail. Within two (2)
business days after receiving the Deposits, Escrow Agent shall verify that the
Deposits are in the proper format and appear to be complete by performing the
verification procedure specified in Appendix 1A or Appendix 1, as applicable. Unless
Escrow Agent and ICANN agree on another method for the delivery of Escrow
Agent’s written certification that it has performed the verification procedure
described in Appendix 1A or Appendix 1, as applicable, and a copy of the
verification reports generated by that procedure, Escrow Agent shall deliver, on the last business day
of each month, a written certification to ICANN that it has performed the
verification procedure described in Appendix 1A or Appendix 1, as applicable,
on all Deposits received during the last month and shall deliver to ICANN a
copy of the verification reports generated by that procedure. If Escrow Agent
discovers that any Deposits fail the verification procedure, Escrow Agent shall
notify ICANN and Registry Operator of such nonconformity within forty-eight
(48) hours. Escrow Agent shall then hold the Deposits in accordance with the
terms and conditions hereof.
2. Duplication. Escrow Agent may duplicate the Deposits by any means
in order to comply with the terms and provisions of this Escrow
Agreement. Alternatively, Escrow Agent, by notice to Registry Operator, may
reasonably require Registry Operator to promptly duplicate the Deposits and
forward the same to Escrow Agent.
3. Notification of Deposits; Distribution of Public Keys.
(a)
Along with the delivery
of each Deposit
to the Escrow Agent, Registry
Operator shall deliver to Escrow Agent and to ICANN a
written statement from Registry Operator pursuant to the terms and conditions
of Section 7 (Notification of Deposits) of Appendix 1A or Appendix 1, as
applicable. Escrow Agent shall, within two (2) business days of receipt of any
Deposit, send notification to Registry Operator either by email or telephone,
or as may be otherwise requested by Registry Operator, and to ICANN
electronically using the API described in the “internet draft” of the ICANN Registry Interfaces specification located at https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces
as of the Effective Date of
this Escrow Agreement, that it has received from Registry Operator such
Deposit. In addition, Escrow Agent shall also include a copy of the
verification report as confirmation that it has run the verification process.
(b)
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.
4. Delivery by Escrow Agent
4.1 Delivery by Escrow Agent
to ICANN. Escrow Agent shall deliver the Deposits, or a
complete copy thereof, to ICANN only in the event that:
(a) Registry Operator notifies Escrow
Agent to effect such delivery to ICANN at a specific address, the notification being
accompanied by a payment
remittance advice to evidence a payment to Escrow Agent in the amount
of one hundred dollars ($100.00); or
(b)
Escrow Agent receives from
ICANN:
(i)
Written notification that the
Registry Agreement has been finally, validly and legally terminated under
Section 6 of the Registry
Agreement and no injunction or similar order
has been obtained from an arbitrator or court prohibiting ICANN from
securing the data in this escrow ("Registry Termination");
(ii) a written statement that ICANN has previously notified
Registry Operator of such Registry Termination in writing;
(iii)
a
written demand that the Deposits
be released and delivered to ICANN;
(iv)
a written
undertaking from ICANN that the Deposits being
supplied to ICANN
will be used only as permitted under the terms of
the Registry Agreement;
(v)
specific instructions from ICANN for this delivery; and
(vi)
a payment remittance advice to evidence a
payment from Registry Operator, or evidence of payment via
email from ICANN (who will then be reimbursed by Registry
Operator), to Escrow Agent in the amount of one hundred dollars ($100.00); or
(c)
a
release occurs according
to Section 8(c) below.
4.2 Delivery at Registry Operator's Request. If the provisions of Section 4.1(a) above are
satisfied, Escrow Agent shall, within
twenty-four (24) hours after receipt of the notification and check specified in Section 4.1(a),
deliver the Deposits in accordance with the applicable instructions.
4.3 Delivery at ICANN's Request. If the provisions of Section 4.1(b) or 4.1(c) above
are satisfied, Escrow Agent shall, within twenty-four (24) hours after receipt
of all the documents specified in those sections, deliver the following: (i) to
Registry Operator, a copy of all such documents; (ii) to ICANN, as specifically
instructed by ICANN, electronic copies of the Deposits; provided, however, that
if the delivery is commenced by reason of Section 4.1(c) above, Registry
Operator may make the payment owing to Escrow Agent during the twenty-four (24)
hour period referenced above, and Escrow Agent shall not thereafter deliver to
ICANN the materials specified in subpart (ii) of this section, above. Following
receipt of the notice to Registry Operator under
subpart (i) of this section,
Registry Operator shall
have thirty (30) days
from the date on which Registry Operator receives such documents ("Objection
Period") to notify Escrow Agent of its objection ("Objection
Notice") to the release of the Deposits to ICANN and request that the
issue of entitlement to a copy of the Deposits be submitted to arbitration in
accordance with the following provisions:
(a)
The sending of an Objection Notice
shall not delay delivery of the Deposits
to ICANN.
(b)
If Registry Operator shall send an
Objection Notice to Escrow Agent during the Objection Period, the matter shall
be submitted to and settled by arbitration by a panel of three (3) arbitrators
chosen by the American Arbitration Association in accordance with the rules of
the American Arbitration Association. The arbitrators shall apply the law of
California exclusive of its conflicts of laws rules.
At least one (1) arbitrator shall be reasonably familiar with the Internet
industry. The decision of the arbitrators shall be binding and conclusive on
all parties involved, and judgment upon their decision may be entered in a
court of competent jurisdiction. All costs of the arbitration incurred by
Escrow Agent, including reasonable attorneys' fees and costs, shall be paid by
the party which does not prevail in the arbitration; provided, however, if the
arbitration is settled prior to a decision by the arbitrators, the parties
involved in the arbitration shall each pay an equal percentage of all such
costs.
(c)
Notwithstanding Section 4.3(b)
above, the parties agree that any arbitration brought pursuant to this Section
4.3 shall not re-evaluate, reconsider, or otherwise subject to review any
issues, causes of action, or other claims which were decided, in an arbitration
or court decision involving the
parties hereto concerning the Registry Agreement and/or the Cooperative
Agreement, and that any decision regarding such issues or claims in an
arbitration brought pursuant to Section
4.3 would be invalid, unenforceable, and not binding.
The propriety, validity, legality, or effectiveness of
any terminations or actions under the Registry Agreement and/or Cooperative
Agreement shall be determined solely through procedures and remedies provided for by those respective agreements, not
through any arbitration brought pursuant to Section 4.3. Any arbitration
proceeding brought pursuant to Section 4.3 shall be limited to a determination
of whether Sections 4.1(b) and (c) have been satisfied.
(d)
Registry Operator may, at any time
prior to the commencement of arbitration proceedings, notify Escrow
Agent that Registry
Operator has withdrawn the Objection Notice.
Upon receipt of any such notice from Registry Operator,
Escrow Agent shall promptly deliver the Deposits to ICANN in accordance with
the instructions provided by ICANN.
(e)
If the release of materials to
ICANN pursuant to Section 4.3 is judged to be proper in any arbitration brought
in accordance with Section 4.3, Escrow Agent shall promptly deliver to ICANN,
in accordance with the instructions specified in Section 4.1(b)(v) above, any
Deposits that have not previously been delivered. All parties agree that Escrow
Agent shall not be required to deliver such Deposits until
all such fees then due to Escrow Agent have been paid.
(f) If the release of the Deposits to
ICANN pursuant to Section 4.3 is judged to have been improper in any
arbitration brought in accordance with Section 4.3, ICANN shall promptly return or destroy, at Registry Operator's discretion, those Deposits
that were received
by ICANN pursuant to Section
4.3.
4.4 Delivery by Escrow Agent to Registry
Operator. Escrow Agent shall release
and deliver the Deposits to
Registry Operator upon termination of this Escrow Agreement in accordance with
Section 7(a) or 7(b) hereof.
5.
Indemnity.
General Indemnity. Subject
to the limitation imposed under Section 11(a) below, Registry Operator and ICANN shall
jointly and severally indemnify and hold harmless Escrow
Agent and each of its
directors, officers, agents and employees ("Escrow Agent
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 Escrow Agent Indemnitee in connection with this Escrow
Agreement or the performance of Escrow Agent or any Escrow Agent Indemnitee
hereunder, except for any claims, actions, damages, suits, liabilities,
obligations, costs, fees, charges, or any other expenses arising in connection
with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors,
officers, agents, employees or contractors. Subject to the limitation imposed
under Section 11(a), Escrow Agent shall likewise indemnify and hold harmless
Registry Operator and ICANN, and each of their respective directors, officers,
agents, and employees ("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.
6. Disputes and Interpleader.
(a)
Escrow Agent may submit any dispute under this Escrow Agreement to any court of
competent jurisdiction in an interpleader or similar action other than a matter
submitted to arbitration after Escrow
Agent's receipt of an Objection Notice under Section
4 above and the
parties under this Escrow Agreement submit the matter to such arbitration as
described in Section 4 of this Escrow Agreement. Any and all costs incurred by
Escrow Agent in connection therewith, including reasonable attorneys' fees and costs, shall
be borne 50% by each of Registry Operator and ICANN.
(b) Escrow Agent shall perform
any acts ordered
by any court of competent jurisdiction, without
any liability or obligation to any party hereunder by reason of such act.
7. Term and Renewal.
(a)
The initial term of this Escrow
Agreement shall commence on the Effective Date hereof and continue for five (5)
years thereafter (the "Initial Term"). This Escrow
Agreement shall be automatically extended for additional terms of one year (each an "Additional Term") at the end of the Initial Term and at the end of each Additional Term
hereunder. The Initial Term and each Additional Term shall be referred to
collectively as the “term.” Escrow Agent acting alone or Registry Operator,
with the concurrence of ICANN,
may terminate this Escrow Agreement at any time upon giving
the other parties ninety (90)
days notice.
(b)
In the event Registry
Operator gives notice
of its intent to terminate pursuant to Section
7(a) above, and ICANN fails to concur according to Section 7(a), ICANN
shall be responsible for payment of all subsequent fees and shall
have the right to seek reimbursement of such fees from
Registry Operator and to terminate this Escrow Agreement at any time upon
giving the other parties ninety (90) days notice.
(c) In
the event of termination of this Escrow
Agreement in accordance with Section 7(a) or 7(b) hereof, Registry Operator shall
pay all fees due Escrow
Agent and shall
promptly notify ICANN that this Escrow Agreement has been
terminated and that Escrow Agent shall return to Registry Operator all copies
of the Deposits then in its possession.
8. Fees and Invoice.
(a) Fees. Registry Operator shall pay Escrow
Agent the Annual Fee set forth in Exhibit A (incorporated by this reference) in
advance in accordance with Section 8 (Fees and Invoice) in exchange for Escrow Agent's
services under this Escrow Agreement.
(b) Invoice Payment. Registry Operator shall pay valid and
properly submitted invoices within thirty (30) days of the date of such
invoice; provided, however, that Registry Operator shall not be obligated to
pay any amounts disputed in good faith. Registry Operator shall notify Escrow
Agent in writing in the event Registry Operator in good faith disputes the
invoice or any portion thereof setting forth the reasons of such dispute, and
the parties agree to negotiate in good faith a resolution to such disputed
invoice; provided, however, that if the parties
cannot reasonably agree on the disputed charges,
the parties shall
escalate such dispute to the
appropriate director/vice president level to resolve such dispute. Payments to
Escrow Agent shall be sent to the remittance address set forth on Escrow
Agent’s invoice.
(c)
Nonpayment. In the event of non-payment of any fees or charges
invoiced by Escrow
Agent, Escrow Agent shall give notice of non-payment of any fee due and
payable hereunder to Registry
Operator and, in such an event, Registry Operator shall have the right to pay
the unpaid fee within ten (10) business
days after receipt
of notice from Escrow Agent.
If Registry Operator fails to pay in full all fees due during such ten (10) day period,
Escrow Agent shall give notice
of non-payment of any fee due and payable hereunder to ICANN and, in
such event, ICANN shall have the right to pay the unpaid fee within ten (10)
business days of receipt of such notice from Escrow Agent. Upon payment of the
unpaid fee by either Registry Operator or ICANN, as the case may be, this
Escrow Agreement shall continue in full force and effect until the end of the
applicable term. Upon a failure to pay the unpaid fee under this Section 8(c)
by either Registry Operator or ICANN, or by Registry Operator under Section
4.3, the Escrow Agent shall proceed as set forth in Section 4.3 as though ICANN
had requested delivery of the Deposits.
(d) Invoice Submission
Address. Escrow Agent shall invoice Registry Operator the Annual
Fee on the Effective Date of this Escrow Agreement and on the anniversary of
the Effective Date for each year thereafter during the term of this Escrow
Agreement. In the event this Escrow Agreement is terminated prior to the end of
the then current term, Escrow Agent shall refund to Registry Operator, or to
ICANN for fees paid by ICANN to Escrow Agent under Section 8(c), a prorated
portion of the Annual Fee based on the date of termination. For any additional
work that may be agreed upon by the parties in a signed writing, Escrow Agent shall
submit detailed and timely invoices not more frequently than once a month and
not later than ninety (90) days after the work performed for such additional
services has been completed. All invoices issued hereunder shall reference the
Purchase Order number assigned to the work performed under this Escrow Agreement. Escrow Agent shall not submit
any invoices to Registry Operator
that do not reference the applicable Purchase
Order number provided that Registry Operator shall be responsible for timely
providing Escrow Agent such applicable Purchase Order number. Escrow Agent
shall submit original invoices solely to Registry Operator’s Accounts Payable
department at the mailing or electronic mailing address as set forth below:
Invoice Submission Address:
VeriSign, Inc.
12061 Bluemont Way
Reston, Virginia 20190
Attn: Accounts Payable
Or Invoices
may be submitted electronically to: accountspayable@verisign.com
9. Ownership of Deposits. The
parties recognize and acknowledge that ownership of the
Deposits during the effective term of this Escrow Agreement shall remain with
Registry Operator at all times.
10. Retention and Confidentiality.
(a)
Retention. Escrow Agent shall hold and maintain the Deposits for
a period of no less than three hundred and sixty-five (365) days in a secure,
locked, and environmentally safe facility which is accessible only to
authorized representatives of Escrow Agent. Escrow Agent shall use commercially
reasonable efforts to protect the integrity of the Deposits. Each of ICANN
and Registry Operator
shall have the right to inspect Escrow
Agent's written records with respect to this Escrow
Agreement upon reasonable prior notice and during
normal business hours.
(b)
Confidentiality. Escrow Agent shall at all times protect the
confidentiality of the Deposits. Except as provided in this Escrow Agreement,
Escrow Agent shall not disclose, transfer, make available, or use any Deposits
(or any copies of any Deposits). Should Escrow Agent be put on notice that it
is required to disclose any Deposits by statute, rule, regulation, order, or
other requirement of a governmental agency, legislative body, court of
competent jurisdiction, or binding arbitral body (other than any requirement pursuant
to Sections 4 or 8(c) of this Escrow Agreement), Escrow Agent shall notify
ICANN and Registry Operator within seven (7) days or as soon as practicable and
reasonably cooperate with Registry Operator and/or ICANN in any contest of the disclosure. Should any contest
prove unsuccessful, Escrow
Agent shall not be held liable for any disclosure pursuant to
such governmental, legislative, judicial, or arbitral order, statute, rule,
regulation, or other requirement.
11.
Miscellaneous.
(a)
Remedies; Limitation of Liability.
(i) Except for liability arising from (i)
death or bodily injury; or (ii) gross negligence, or willful misconduct, in any
dispute between Registry Operator and/or ICANN on the one hand and Escrow Agent on the other hand,
all liability of Escrow Agent,
Registry Operator and/or
ICANN related to this Escrow Agreement, if any, whether arising in
contract, tort (including
negligence) or otherwise, shall be limited to an amount equal to the then
annual fees paid to Escrow Agent under this Escrow Agreement.
(ii) As
between Registry Operator
and ICANN the liability limitations of the Registry
Agreement also apply.
(iii)
In no event shall any party to
this Escrow Agreement be liable to another party for any incidental, special,
punitive or consequential damages, lost profits,
any costs or expenses for the
procurement of substitute services (excluding substitute escrow services), or
any other indirect damages, whether arising in contract, tort (including
negligence) or otherwise even if the possibility thereof may be known in
advance to one or more parties.
(iv)
Each party
expressly reserves all rights in law or equity to enforce the provisions of this
Escrow Agreement, subject only to the limitations set forth in this Section
11(a).
(b)
Permitted Reliance
and Abstention. Escrow Agent may rely and shall be fully protected in acting or refraining from acting upon any notice
or other document
believed by Escrow
Agent in good faith to be
genuine and to have been signed or presented by the proper person or entity.
Escrow Agent shall have no duties or responsibilities except those expressly
set forth herein.
(c)
Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of either Registry
Operator or ICANN.
(d)
Amendments. This Escrow Agreement shall not be modified or amended except
by another agreement in
writing executed by each of the parties hereto.
(e)
Assignment. Neither Registry Operator nor ICANN may assign or
transfer this Escrow Agreement (by merger, sale of assets, operation of law, or
otherwise), except that the rights and obligations of Registry Operator or
ICANN automatically shall be transferred to the assignee of one of those
parties' rights and obligations under the Registry Agreement. However, Escrow
Agent shall have no obligation in performing this Escrow Agreement
to recognize any successor
or assign of Registry Operator or ICANN unless Escrow Agent receives clear,
authoritative and conclusive written evidence of the change of parties. Escrow
Agent may not assign or transfer this Escrow Agreement without the prior written consent
of both Registry
Operator and ICANN, which consent shall not be
unreasonably delayed or withheld.
(f)
Entire Agreement. This Escrow
Agreement, including all exhibits hereto
(if any), supersedes all prior discussions, understandings and agreements between
Escrow Agent and the other parties
with respect to the matters contained herein, and constitutes the entire
agreement between Escrow Agent and the other parties with respect to the
matters contemplated herein. Appendix 1A or Appendix 1, as applicable, of the
Registry Agreement is by this reference made a part of this Escrow Agreement
and incorporated herein.
(g)
Counterparts; Governing
Law. This Escrow Agreement may be
executed in counterparts, each of which when so executed shall be deemed to be
an original and all of which when taken together shall constitute one and the same agreement. This Escrow Agreement shall be governed by and interpreted in accordance
with the laws of California, without regard to its conflicts of law principles.
Except as specifically provided for herein, all of the parties additionally
consent to the personal jurisdiction of California, acknowledge that venue is
proper in any state and Federal court in California, agree to any action
related to this Escrow Agreement properly brought in one of these courts, and
waive any objection it has or may have in the future with respect to any of the
foregoing.
(h)
Notices. All notices, requests, demands or other communications
required or permitted to be given or made under this Escrow Agreement
shall be in writing and shall be delivered by hand or by commercial overnight delivery
service which provides for evidence of receipt, or mailed by certified mail, return receipt
requested, postage prepaid.
If delivered personally or by commercial overnight delivery service, the
date on which the notice, request, instruction or document is delivered shall
be the date on which delivery is deemed to be made, and if delivered by mail,
the date on which such notice, request, instruction or document is received
shall be the date on which delivery
is deemed to be made. Any party may change its address for the purpose of this
Escrow Agreement by notice in writing to the other parties as provided herein.
(i) Survival. Sections 5, 6, 8, 9, 10 and 11 shall survive
any termination of this Escrow Agreement.
(j)
No Waiver. No failure on the part of any party hereto to exercise,
and no delay in exercising any right, power or single or partial exercise of
any right, power or remedy by any party will preclude any other or further exercise
thereof or the exercise of any other
right, power or remedy.
No express waiver or assent by any party hereto to any breach of or default in
any term or condition of this Escrow Agreement shall constitute a waiver of or
an assent to any succeeding breach of or default in the same or any other term
or condition hereof.
IN WITNESS
WHEREOF each of the parties
has caused its duly authorized officer to execute this Escrow Agreement as of the Effective
Date.
[ ]
By:
Title:
Print Name:
Date:
Address:
Phone:
E-mail:
VeriSign, Inc.
By:
Title:
Print Name:
Date:
Address:
Phone:
E-mail:
Internet Corporation for Assigned
Names and Numbers
By:
Title:
Print Name:
Date:
Address:
Phone:
E-mail:
Exhibit
A to Appendix 2
1. Annual Fee.
The Annual Fee shall be [ ] United States Dollars.
2. Testing Period. Notwithstanding
anything to the contrary in this Escrow Agreement, upon the Effective Date of
the Escrow Agreement until reasonably determined by Registry Operator as
indicated by notice, which may be via email, from Registry Operator to ICANN
and Escrow Agent, Escrow Agent shall perform the services set forth in this
Escrow Agreement in parallel with the legacy escrow agent for the purposes of
demonstrating that the Escrow Agent is performance ready (the “Testing
Period”). ICANN understands and agrees that during the Testing Period, the
legacy escrow agent shall continue to be the sole authoritative source of
escrow services.
.com
Registry Agreement Appendix 3
Zone
File Access
1. Third-Party Zone
File Access
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 1.3 of this Appendix and do so using the file format described in
Section 1.4 of this Appendix. 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 1.2 of this Appendix; (b) Registry Operator may reject the request for
access of any user that does not provide correct or legitimate credentials
under Section 1.2 of this Appendix or where Registry Operator reasonably
believes will violate the terms of Section 1.5 of this Appendix; 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 1.5 of this
Appendix.
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.
1.3 Grant of Access. Each Registry
Operator (optionally through the CZDA Provider) will provide the Zone File SFTP
(or other Registry supported) service for an ICANN-specified and managed URL
(specifically, <TLD>.zda.icann.org where <TLD> is the TLD for which
the registry is responsible) for the user to access the Registry’s zone data
archives. Registry Operator will grant the user a non‐exclusive,
nontransferable, limited right to access Registry Operator’s (optionally CZDA
Provider's) Zone File hosting server, and to transfer a copy of the top-level
domain zone files, and any associated cryptographic checksum files no more than
once per 24 hour period using SFTP, or other data transport and access
protocols that may be prescribed by ICANN. For every zone file access server,
the zone files are in the top-level directory
called <zone>.zone.gz,
with <zone>.zone.gz.md5 and <zone>.zone.gz.sig to verify downloads.
If the Registry Operator (or the CZDA Provider) also provides historical data,
it will use the naming pattern <zone>-yyyymmdd.zone.gz, etc.
1.4 File Format
Standard.
Registry Operator (optionally through the CZDA Provider) will provide zone
files using a subformat of the standard Master File format as originally
defined in RFC 1035, Section
5, including all the records present in the actual zone used in the public DNS.
Sub-format is as follows:
1. Each record must
include all fields in one line as: <domain‐name> <TTL>
<class> <type>
<RDATA>.
2. Class and Type
must use the standard mnemonics and must be in lower case.
3. TTL must be
present as a decimal integer.
4. Use of \X and \DDD
inside domain names is allowed.
5. All domain names
must be in lower case.
6. Must use exactly
one tab as separator of fields inside a record.
7. All domain names
must be fully qualified.
8. No $ORIGIN directives.
9. No use of “@” to
denote current origin.
10.
No
use of “blank domain names” at the beginning of a record to continue the use of the domain name in the previous record.
11. No $INCLUDE directives.
12. No $TTL directives.
13. No use of
parentheses, e.g., to continue the list of fields in a record across a line boundary.
14. No use of comments.
15. No blank lines.
16. The SOA record
should be present at the top and (duplicated at) the end of the zone file.
17. With the exception
of the SOA record, all the records in a file must be in alphabetical order.
18. One zone per file.
If a TLD divides its DNS data into multiple zones, each zone goes into a separate file named as above, with all
the files combined using tar into a file called
<tld>.zone.tar.
1.5 Use of Data by
User.
Registry Operator will permit user to use the zone file for lawful purposes;
provided that (a) user takes all reasonable steps to protect against
unauthorized access to, use of, and
disclosure of the data, and (b) under no circumstances will Registry Operator
be required or permitted to allow user to use the data to (i) allow, enable or
otherwise support any marketing
activities to entities other than the user’s existing customers, regardless of
the medium used (such media include but are not limited to transmission by
e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts of mass
unsolicited, commercial advertising or solicitations to entities), (ii) enable
high volume, automated, electronic processes that send queries or data to the
systems of Registry Operator or any ICANN-accredited registrar, or (iii)
interrupt, disrupt or interfere in the normal business operations of any
registrant.
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.
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.
Co‐operation
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 Appendix.
2.2
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.
.com
Registry Agreement Appendix 4 Format and Content for Registry Operator Monthly
Reporting
Registry Operator
shall provide the following monthly reports, each as described in greater detail below, for the TLD: (1) the
Service Level Agreement Performance Report; (2) the Per-Registrar Transactions
Report; and (3) the Registry Functions Activity Report. The Service Level
Agreement Performance Reports shall be submitted to ICANN via email to <registry- reports@icann.org>. The
Per-Registrar Transactions Reports and the Registry Functions Activity Reports
shall be submitted to ICANN using the API described in draft-lozano-icann-
registry-interfaces, see https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces
(the “Registry Interfaces Specification”). If not already an RFC, Registry
Operator will use the most recent draft version of the Registry Interfaces
Specification available as of December 1, 2024. Registry Operator may at its
election use newer versions of the Registry Interfaces Specification after December
1, 2024. Once the Registry Interfaces Specification is published as an RFC,
Registry Operator will implement the RFC version no later than one hundred
eighty (180) calendar days after it is published.
ICANN
may request in the future that the reports be delivered by other means and
using other formats. For each of the reports, 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 Appendix 4, 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.
Service
Level Agreement Performance Report. This report shall compare the Service
Level Agreement requirements with actual performance measures for the reporting month: (a) in accordance with Section 7.2
of Appendix 7; and (b) in accordance with Section 3.2 of Appendix 5B.
2.
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 “com-transactions-yyyymm.csv.” The file shall contain the following
fields per registrar:
|
Field
#
|
Field name
|
Description
|
|
01
|
registrar-name
|
Registrar’s full
corporate name as registered with IANA
|
|
02
|
iana-id
|
For cases where
the registry operator acts as registrar (i.e., without the use of an ICANN
accredited
|
|
|
|
registrar)
either 9998 or 9999 should be used depending on registration type, otherwise
the sponsoring Registrar IANA id should be used as specified in
https://www.iana.org/assignments/registrar-ids
|
|
03
|
total-domains
|
total domain
names under sponsorship in any EPP status but pendingCreate that have not
been purged
|
|
04
|
total-nameservers
|
total name
servers (either host objects or name server hosts as domain name attributes)
associated with domain names registered for the TLD in any EPP status but
pendingCreate that have not been purged
|
|
05
|
net-adds-1-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of one (1) year (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
06
|
net-adds-2-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of two(2) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
07
|
net-adds-3-yr
|
number
of domains successfully registered (i.e., not in EPP pendingCreate status)
with an initial term of three (3) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
08
|
net-adds-4-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of four (4) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
09
|
net-adds-5-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of five (5) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
10
|
net-adds-6-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of
|
|
|
|
six (6) years
(and not deleted within the add grace period). A transaction must be reported
in the month the add grace period ends.
|
|
11
|
net-adds-7-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of seven (7) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
12
|
net-adds-8-yr
|
number
of domains successfully registered (i.e., not in EPP pendingCreate status)
with an initial term of eight (8) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
13
|
net-adds-9-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of nine (9) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
14
|
net-adds-10-yr
|
number of
domains successfully registered (i.e., not in EPP pendingCreate status) with
an initial term of ten (10) years (and not deleted within the add grace
period). A transaction must be reported in the month the add grace period
ends.
|
|
15
|
net-renews-1-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of one (1) year (and
not deleted within the renew or auto-renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
16
|
net-renews-2-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of two (2) years (and
not deleted within the renew or auto-renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
17
|
net-renews-3-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by
command with a
new renewal period of three (3)
|
|
|
|
years (and not
deleted within the renew or auto- renew grace period). A transaction must be
reported in the month the renew or auto-renew grace period ends.
|
|
18
|
net-renews-4-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of four (4) years (and not deleted within the renew
or auto-renew grace period). A transaction must be reported in the month the
renew or auto-renew grace period ends.
|
|
19
|
net-renews-5-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of five (5) years (and
not deleted within the renew or auto-renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
20
|
net-renews-6-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of six (6) years (and
not deleted within the renew or auto-renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
21
|
net-renews-7-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of seven (7) years (and
not deleted within the renew or auto- renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
22
|
net-renews-8-yr
|
number of domains
successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of eight (8) years (and
not deleted within the renew or auto- renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
23
|
net-renews-9-yr
|
number
of domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of nine (9)
|
|
|
|
years (and not
deleted within the renew or auto- renew grace period). A transaction must be
reported in the month the renew or auto-renew grace period ends.
|
|
24
|
net-renews-10-yr
|
number of
domains successfully renewed (i.e., not in EPP pendingRenew status) either
automatically or by command with a new renewal period of ten (10) years (and
not deleted within the renew or auto- renew grace period). A transaction must
be reported in the month the renew or auto-renew grace period ends.
|
|
25
|
transfer-gaining-successful
|
number of domain
transfers initiated by this registrar that were successfully completed
(either explicitly or automatically approved) and not deleted within the
transfer grace period. A transaction must be reported in the month the
transfer grace period ends.
|
|
26
|
transfer-gaining-nacked
|
number
of domain transfers initiated by this registrar that were rejected (e.g., EPP
transfer op="reject") by the other registrar
|
|
27
|
transfer-losing-successful
|
number of domain
transfers initiated by another registrar that were successfully completed
(either explicitly or automatically approved)
|
|
28
|
transfer-losing-nacked
|
number of domain
transfers initiated by another registrar that this registrar rejected (e.g.,
EPP transfer op="reject")
|
|
29
|
transfer-disputed-won
|
number of
transfer disputes in which this registrar prevailed (reported in the month
where the determination happened)
|
|
30
|
transfer-disputed-lost
|
number of
transfer disputes this registrar lost (reported in the month where the
determination happened)
|
|
31
|
transfer-disputed-nodecision
|
number of
transfer disputes involving this registrar with a split or no decision
(reported in the month where the determination happened)
|
|
32
|
deleted-domains-grace
|
domains deleted
within the add grace period (does not include names deleted while in EPP
pendingCreate status). A deletion must be reported in the month the name is
purged.
|
|
33
|
deleted-domains-nograce
|
domains deleted
outside the add grace period (does not include names deleted while in EPP
pendingCreate status). A deletion must be reported in the month the name is
purged.
|
|
34
|
restored-domains
|
domain names
restored during reporting period
|
|
35
|
restored-noreport
|
total number of restored
names for which a restore report is required by the registry, but the
registrar failed to submit it
|
|
36
|
agp-exemption-requests
|
total number of
AGP (add grace period) exemption requests
|
|
37
|
agp-exemptions-granted
|
total number of
AGP (add grace period) exemption requests granted
|
|
38
|
agp-exempted-domains
|
total number of
names affected by granted AGP (add grace period) exemption requests
|
|
39
|
attempted-adds
|
number of
attempted (both successful and failed) domain name create commands
|
|
40
|
consolidate-transaction-days
|
total number of
days added to the expiration date of all domain names via consolidate/sync
transactions. The number of days of a consolidate/sync transaction must be
reported here in the month the transaction took place.
|
|
41
|
consolidate-transactions
|
total number of
consolidate/sync transactions. A transaction must be reported in the month
the transaction took place.
|
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.
3.
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 “com-activity-yyyymm.csv.”
The file shall contain the following fields:
|
Field
#
|
Field Name
|
Description
|
|
01
|
operational-registrars
|
number of
operational registrars in the production system at the end of the reporting
period
|
|
02
|
zfa-passwords
|
number of active
zone file access passwords at the end of the reporting period;
"CZDS" may be used instead of the number of active zone file access
passwords, if the Centralized Zone Data Service (CZDS) is used to provide the
zone file to the end user
|
|
03
|
whois-43-queries
|
number of WHOIS
(port-43) queries responded during the reporting period
|
|
04
|
web-whois-queries
|
number of web-based
WHOIS queries responded during the reporting period, not including searchable
WHOIS
|
|
05
|
searchable-whois-queries
|
number of
searchable WHOIS queries responded during the reporting period
|
|
06
|
dns-udp-queries-received
|
number of DNS
queries received over UDP transport during the reporting period
|
|
07
|
dns-udp-queries-responded
|
number of DNS
queries received over UDP transport that were responded during the reporting
period
|
|
08
|
dns-tcp-queries-received
|
number of DNS
queries received over TCP transport during the reporting period
|
|
09
|
dns-tcp-queries-responded
|
number of DNS
queries received over TCP transport that were responded during the reporting
period
|
|
10
|
srs-dom-check
|
number of SRS
(EPP and any other interface) domain name “check” requests responded during
the reporting period
|
|
11
|
srs-dom-create
|
number of SRS
(EPP and any other interface) domain name “create” requests responded during
the reporting period
|
|
12
|
srs-dom-delete
|
number of SRS
(EPP and any other interface) domain name “delete” requests responded during
the reporting period
|
|
13
|
srs-dom-info
|
number of SRS
(EPP and any other interface) domain name “info” requests responded during
the reporting period
|
|
14
|
srs-dom-renew
|
number of SRS
(EPP and any other interface) domain name “renew” requests responded during
the reporting period
|
|
15
|
srs-dom-rgp-restore-report
|
number of SRS
(EPP and any other interface) domain name RGP “restore” requests delivering a
restore report responded during the reporting period
|
|
16
|
srs-dom-rgp-restore-request
|
number of SRS
(EPP and any other interface) domain name RGP “restore” requests responded
during the reporting period
|
|
17
|
srs-dom-transfer-approve
|
number of SRS
(EPP and any other interface) domain name “transfer” requests to approve
transfers responded during the reporting period
|
|
18
|
srs-dom-transfer-cancel
|
number of SRS
(EPP and any other interface) domain name “transfer” requests to cancel
transfers responded during the reporting period
|
|
19
|
srs-dom-transfer-query
|
number of SRS
(EPP and any other interface) domain name “transfer” requests to query about
a transfer responded during the reporting period
|
|
20
|
srs-dom-transfer-reject
|
number of SRS
(EPP and any other interface) domain name “transfer” requests to reject
transfers responded during the reporting period
|
|
21
|
srs-dom-transfer-request
|
number of SRS
(EPP and any other interface) domain name “transfer” requests to request
transfers responded during the reporting period
|
|
22
|
srs-dom-update
|
number of SRS
(EPP and any other interface) domain name “update” requests (not including
RGP restore requests) responded during the reporting period
|
|
23
|
srs-host-check
|
number of SRS
(EPP and any other interface) host “check” requests responded during the
reporting period
|
|
24
|
srs-host-create
|
number of SRS
(EPP and any other interface) host “create” requests responded during the
reporting period
|
|
25
|
srs-host-delete
|
number of SRS
(EPP and any other interface) host “delete” requests responded during the
reporting period
|
|
26
|
srs-host-info
|
number of SRS
(EPP and any other interface) host “info” requests responded during the
reporting period
|
|
27
|
srs-host-update
|
number of SRS
(EPP and any other interface) host “update” requests responded during the
reporting period
|
|
28
|
srs-cont-check
|
number of SRS
(EPP and any other interface) contact “check” requests responded during the
reporting period
|
|
29
|
srs-cont-create
|
number of SRS
(EPP and any other interface) contact “create” requests responded during the
reporting period
|
|
30
|
srs-cont-delete
|
number of SRS
(EPP and any other interface) contact “delete” requests responded during the
reporting period
|
|
31
|
srs-cont-info
|
number of SRS
(EPP and any other interface) contact “info” requests responded during the
reporting period
|
|
32
|
srs-cont-transfer-approve
|
number of SRS
(EPP and any other interface) contact “transfer” requests to approve
transfers responded during the reporting period
|
|
33
|
srs-cont-transfer-cancel
|
number
of SRS (EPP and any other interface) contact “transfer” requests to cancel
transfers responded during the reporting period
|
|
34
|
srs-cont-transfer-query
|
number of SRS
(EPP and any other interface) contact “transfer” requests to query about a
transfer responded during the reporting period
|
|
35
|
srs-cont-transfer-reject
|
number of SRS
(EPP and any other interface) contact “transfer” requests to reject transfers
responded during the reporting period
|
|
36
|
srs-cont-transfer-request
|
number
of SRS (EPP and any other interface) contact “transfer” requests to request
transfers responded during the reporting period
|
|
37
|
srs-cont-update
|
number of SRS
(EPP and any other interface) contact “update” requests responded during the
reporting period
|
|
38
|
rdap-queries
|
number of RDAP
queries 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
the TLD that is a part of a single-instance Shared Registration System: (1) the
fields whois-43-queries, web-whois-queries, searchable-whois-queries and
rdap-queries in the Registry Functions Activity Report should match the sum of
queries reported for the TLDs in the single-instance Shared Registration
System, and Registry Operator has the flexibility to choose how to allocate
those queries across the TLDs utilizing the single-instance Shared Registration
System, (2) in case of queries related to the fields in (1) above for which the
Registry Operator cannot determine the TLD to count the query to (e.g., a
registrar lookup query for a registrar operating in more than one TLD sharing
the same RDAP base URL), registry operator has the flexibility to choose how to
allocate those queries across the TLDs utilizing the single-instance Shared
Registration System, and (3) the Registry Functions Activity Report may include
the total contact or host transactions for all the TLDs in the system.
.com Registry Agreement Appendix 5A
Registration Data Publication Services Specification
A. Definitions.
i. Registration Data
Directory Services. Registration Data Directory Services or “RDDS”
refers to the collective of WHOIS Data Directory Services (as defined in this
Appendix 5A) and RDAP Directory Services, as defined in Appendix 5B.
ii. WHOIS
Data Directory Services. WHOIS Data Directory Services refers to
the collective of WHOIS service available via port 43 in accordance with RFC
3912 and a web-based WHOIS service providing free public query-based access to
registration data.
1. WHOIS Data
Directory Services.
Registry Operator will operate a WHOIS service available via port 43 in
accordance with RFC 3912, and a web-based WHOIS Service at
<www.verisign.com/whois> providing free public query-based access to at
least the following elements in the following format.
1.1 The
format of responses shall follow a semi-free text format outlined 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 must
implement only those sections of the Registry Registration Data Directory
Services Consistent Labeling and Display Policy (https://www.icann.org/resources/pages/rdds-labeling-policy-2024-02-21-en) in conjunction
with this Appendix 5A that are relevant to the type of TLD operated, e.g.,
“thick” or “thin” registry model (e.g. exclude information from any contact:
registrant, admin, tech, billing etc.). As of the Effective Date, the .com TLD
is considered a “thin” registry model.
1.5
Domain Name Data
1.5.1 Query
format: whois EXAMPLE.TLD
1.5.2 Response
format:
Domain Name: EXAMPLE.TLD
Registry Domain ID: D1234567-TLD
Registrar WHOIS Server: whois.example.tld
Registrar 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
Registrar Registration Expiration Date:
2010-10-08T00:44:59Z1
Registrar: EXAMPLE REGISTRAR LLC
Registrar IANA ID: 5555555
Registrar Abuse Contact Email: email@registrar.tld
Registrar Abuse Contact Phone:
+1.1235551234
Reseller: EXAMPLE RESELLER1
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registry 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
Registry 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 Registry 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
URL of the ICANN Whois Inaccuracy
Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS
database: 2009-05-29T20:15:00Z <<<
1.6 Registrar
Data
1.6.1 Query
format: whois “registrar Example Registrar, Inc.”
1.6.2 Response
format:
Registrar: 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
Registrar WHOIS Server:
whois.example-registrar.tld
Registrar URL:
http://www.example-registrar.tld Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email:
joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email:
janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email:
johngeek@example-registrar.tld
>>> Last update of WHOIS
database: 2009-05-29T20:15:00Z <<<
1.7 Nameserver
Data:
1.7.1 Query
format: whois “nameserver (nameserver name)”, or whois “nameserver (IP
Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.
1.7.2 Response
format:
Server Name: NS1.EXAMPLE.TLD
IP Address: 192.0.2.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Registrar WHOIS Server:
whois.example-registrar.tld
Registrar 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.
2. RDDS
Policy and Educational Materials. 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
RDDS policy and educational materials.
3. Searchability. Offering
searchability capabilities for the registration data provided via RDDS is
optional but if offered by the Registry Operator it shall comply with the
specification described in this section.
3.1 Registry
Operator will offer searchability as a web-based service.
3.2 Registry
Operator will offer partial match capabilities on each of 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.), and may offer partial match capabilities on
other fields, in each case subject to applicable law.
3.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).
3.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.
3.5 Search
results will include domain names matching the search criteria.
3.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 and ICANN
Consensus Policies and Temporary Policies.
3.7 Registry
Operator shall only offer the searchability capabilities required in the RDAP
Technical Implementation Guide and RDAP Response Profile in the RDAP Directory
Services, as described in Section 2.1 of Appendix 5B.
4. Registration Data Directory Services (RDDS) Requirements. As of December 1,
2024, Registry Operator shall comply with the following requirements:
4.1. Registry
Operator shall offer public IPv6 and IPv4 transports for its RDDS.
4.2. In order
to ensure that authoritative information about the TLD remains publicly
available,
Registry Operator shall submit a change request to the IANA functions operator
updating any outdated or inaccurate DNS, WHOIS or RDAP base URL of the RDAP
Directory Services records of the TLD. Registry Operator shall use commercially
reasonable efforts to submit any such change request no later than seven (7)
calendar days after the date any such DNS, WHOIS or
RDAP base URL of the RDAP service records becomes
outdated or inaccurate. Registry Operator must submit all change requests in
accordance with the procedures set forth at https://www.iana.org/domains/root.
4.3. Personal
data included in the registration data must be redacted in accordance with
ICANN Consensus Policies and Temporary Policies.
4.4. Registry
Operator must adhere to the requirements related to additional fields of the
Consistent Labeling and Display Consensus Policy if Registry Operator chooses
to add data fields.
4.5 In the
event of a conflict between the Registration Data Directory Service requirements
and Consensus Policies or any Temporary Policy, the Consensus Policies or
Temporary Policy shall control, but only with respect to subject matter in
conflict and in accordance with Section 3.1(b) (Consensus Policies) of the
Agreement.
4.6. Until such
time that updates are made and effective for Consensus Policies and procedures
pursuant to the Phase 1 GNSO Consensus Policy recommendations of the Expedited
Policy Development Process on the Temporary Specification for gTLD Registration
Data, adopted by the ICANN Board in May 2019, the following terms in such
policies will be interpreted as follows:
4.6.1 With the
exception of “Searchable Whois” and the “Whois contact lookup service”, the
following terms: “WHOIS”, “Whois”, “Whois service”, “Publicly accessible
Whois”, and variations thereof shall be interpreted to refer to RDDS as defined
in this Appendix.
4.6.2 “Whois data”,
“WHOIS information”, “Whois contact information”, “WHOIS query data”, “WHOIS
details”, “Whois output”, “Whois record”, “Whois entry”, and variations thereof
shall be interpreted to refer to registration data as referenced in this
Appendix.
4.7. Cooperation
with Transition Studies. If ICANN initiates or commissions a study on the
transition of WHOIS Data Directory Services to RDAP Directory Services,
Registry Operator shall reasonably cooperate with such study, including by
delivering to ICANN or its designee conducting such study, both quantitative
and qualitative data related to its experience offering RDAP Data Directory
Services. If the data request is beyond what the Registry Operator collects in
the ordinary course of its operations and beyond the data that Registry
Operator is required to collect and provide to ICANN org pursuant to this
Agreement, Registry Operator should voluntarily cooperate to provide the
requested information or provide an explanation to ICANN why the Registry
Operator is not able to provide the requested information. The terms of this
section do not require Registry Operator to provide data to ICANN that is
beyond what Registry Operator is obligated to provide ICANN pursuant to other
sections of this Agreement. Any data delivered to ICANN or its designee
pursuant to this section that is appropriately marked as confidential shall be
treated as confidential information of Registry Operator, provided that,
notwithstanding the Agreement, if ICANN or its designee aggregates and makes
anonymous such data, ICANN or its designee may disclose such data to any third
party. Following completion of the transition study for which Registry Operator
has provided data, ICANN will destroy all data provided by Registry Operator
pursuant to this section that has not been aggregated and made anonymous.
5. Bulk
Registration Data Access to ICANN
5.1 Periodic
Access to Thin Registration Data. In order to verify and ensure the
operational stability of the Registry Services, analyze the operational
stability of the DNS and facilitate compliance checks and audits of accredited
registrars, Registry Operator will provide ICANN on a daily basis with
up-to-date registration data as specified in this Section 5.1. Data will
include data committed as of 00:00:00 UTC on the previous day. On an annual
basis, ICANN will publish a summary of the research projects that utilized this
data in the preceding year, along with a listing of any organizations the raw
data was shared with to conduct the research.
5.1.1 Contents.
Registry Operator will provide 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, Registry Operator will provide:
registrar name, registrar ID (IANA ID), hostname of registrar WHOIS server (which shall
continue to be provided after
January 28, 2025, if
provided by registrar)
and URL of registrar. Registry Operator shall not provide any additional data
elements.
5.1.2 Format.
The data will be provided in the format specified in Appendix 1 Data Escrow
Specification (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.
5.1.3 Access.
Registry Operator will have the file(s) ready for download as of 00:00:00 UTC
for retrieval by ICANN. The file(s) will be made available for download by
SFTP, though ICANN may request other means in the future.
5.2 Exceptional
Access to Thick Registration Data. This Section 5.2 shall only apply on or
after the date the TLD is operated as a “thick” registry model, if any. 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 Appendix 1 Data Escrow Specification. 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 5.1 of this Appendix.
.com Registry Agreement Appendix 5B
Registration Data Access Protocol Service Specification
1.
Scope and Definitions.
1.1. [RESERVED]
1.2. [RESERVED]
1.3.
“Registration Data Access
Protocol” or “RDAP” is an Internet protocol that provides “RESTful” web
services to retrieve registration metadata from domain name registries and
regional internet registries.
1.4. “RDAP Directory Services” or
“RDAP-RDDS” refers to a Registration Data Directory Service using the RDAP
described in STD 95 (https://www.rfc-editor.org/refs/ref-std95.txt), and its
successor standards.
1.5. “RDAP-query
RTT” refers to the round-trip time (“RTT”) of the sequence of packets from the
start of an RDAP-RDDS testing probe’s TCP connection to its end, including the
reception of the HTTPS response for only one HTTPS request. If the RTT is 5
times or more the corresponding SLR/performance specifications, the RTT will be
considered undefined.
1.6. “RDAP
Availability” refers to the ability of the RDAP-RDDS service 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 RDAP testing probes see the
RDAP-RDDS service as unavailable during a given time, the RDAP-RDDS service
will be considered unanswered.
1.7. “RDAP Update
Time” refers to the time measured from the receipt of an EPP confirmation to a
transform command on a domain name, host or contact, up until at least 51% of
the verifiably working RDAP-RDDS testing probes detect the changes made.
2. RDAP
Directory Services.
2.1 Registry Operator shall implement
the most recent version of the RDAP Technical Implementation Guide and RDAP
Response Profile posted at https://icann.org/gltd-rdap-profile. Registry
Operator will implement new versions of the RDAP Technical Implementation Guide
and RDAP Response Profile no later than one hundred eighty (180) calendar days
after notification from ICANN.
2.2 Registry
Operator shall provide lookup query support for:
2.2.1 domain
information as described in the section “Domain Path Segment Specification” of
RFC 9082.
2.2.2 nameserver
information as described in the section “Nameserver Path Segment Specification”
of RFC 9082; provided, however, that Registry Operator shall not be required to
(but may still choose to) support nameserver lookup if Registry Operator
specifies name servers as domain attributes in EPP.
2.2.3 registrar
information as described in the section “Entity Path Segment Specification” of
RFC 9082.
2.2.4 help
information as described in the section "Help Path Segment
Specification" of RFC 9082.
3. Service Level
Requirements. Registry
Operator shall meet each of the following Service Level Requirements:
3.1. Service Level Requirements Matrix
|
|
Parameter
|
Service
Level Requirements (SLR)/Performance Specification (monthly basis)
|
|
RDAP-RDDS
|
RDAP Availability
|
≦ 864 min of downtime (98%)
|
|
|
RDAP query RTT
|
≦ 4000 ms, for at least 95% of the queries
|
|
|
RDAP Update Time
|
≦ 60 min, for at least 95% of the updates
|
3.2. Registry
Operator shall monitor and measure its performance of the RDAP-RDDS Service
Level Requirements set forth in Section 3.1 above using Registry Operator’s
monitoring probes for the sole purpose of: (a) determining Registry Operator’s
performance of the RDAP-RDDS service for the calculation of SLA Credits to
registrars, if any; and (b) providing RDAP Service Level Requirement
performance data to ICANN in accordance with Appendix 4, Section 1 (Service
Level Agreement Performance Report).
3.3. Registry
Operator is encouraged to do maintenance for RDAP at the times and dates of
statistically lower traffic for each parameter. However, there is no provision
for planned outages or similar periods of unavailability; any downtime, be it
for maintenance or due to system failures, will be noted simply as downtime and
counted for Service Level Requirement measurement purposes.
3.3.1 In the
event that Registry Operator plans RDAP 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.
3.4. The remedies
for a failure to meet an RDAP Service Level Requirement set forth in Section
3.1 shall be equivalent to the remedies under this Agreement for a failure to
meet the corresponding Performance Specification for the WHOIS service,
provided, however, that in the event of a failure of the RDAP-RDDS service and
WHOIS service in a given month, SLA Credits, if applicable, for Registrars
shall not exceed the total amount of SLA Credits attributable solely to the
failure of the service level requirement for the WHOIS service, pursuant to
Registry Operator’s Agreement.
3.5. [RESERVED].
3.6. The parties
agree that the SLA Credits as described in Section 3.4 above are the total
credits, penalties and/or liabilities that may be assessed to Registry Operator
and the sole remedies available to registrar for Registry Operator’s failure to
meet the Service Level Requirements for the RDAP-RDDS service.
3.7. Registry
Operator will use commercially reasonable efforts to restore the RDAP-RDDS
service functionality within 24 hours after the termination of a force majeure
event. Outages due to a force majeure will not be considered service
unavailability for purposes of Appendix 7 or the Service Level Requirements.
3.8. Registry
Operator shall not be liable to ICANN or registrars for any credits or
penalties, or be deemed to be in breach of any of its obligations under the
Agreement, if it fails to meet a Service Level Requirement for the RDAP-RDDS
service as a result of its compliance with any Consensus Policy established
after the Effective Date, to the extent and for so long as, the failure to meet
the Service Level Requirement for the RDAP-RDDS service is unavoidable by
commercially reasonable efforts due to Registry Operator's compliance with such
Consensus Policy.
3.9. The Service
Level Requirements set forth in Section 3 of this Appendix 5B for the RDAP-RDDS
service and the RDAP Measurement Parameters set forth in Section 4.5 of this
Appendix 5B for the RDAP-RDDS service shall be considered “Performance
Specifications” and the “RDAP-RDDS” service shall be considered a “System
Service” for purposes of this Agreement and shall be treated as though set
forth in Appendix 7.
3.10. In order to
determine the appropriate credit level and calculation of an SLA Credit due to
a failure by the Registry Operator to meet a Service Level Requirement, the
credit level and calculation shall be based on the equivalent reference set
forth in the chart below and in accordance with this Agreement.
|
RDAP-RDDS
Service Level Requirement
|
Equivalent
Reference for Purposes of Calculating the Credit Level of the SLA
Credit
|
|
RDAP
Availability
|
Service
Availability--Whois
|
|
RDAP-query
RTT
|
Processing
Time--Whois Query
|
|
RDAP
Update Time
|
Update
Frequency--Whois
|
3.11. The notice
requirement in Section 8.1 of Appendix 7 to be provided by the losing registrar
in a Bulk Transfer After Partial Portfolio Acquisition shall include a
description of how the RDDS record will change after such bulk transfer occurs.
4. RDAP Measurement
Parameters.
4.1. RDAP test.
Means one query sent to a particular IP address of one of the servers of the
RDAP-RDDS service. 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 RDAP test are: a number in milliseconds corresponding to the
RDAP-query RTT or unanswered.
4.2. Measuring
RDAP parameters. Every 5 minutes, each of the RDAP-RDDS probes will select one IP address from
all the public-DNS registered “IP addresses” of the servers of the RDAP-RDDS
service of the TLD being monitored and make an “RDAP
test”. If an RDAP test result is unanswered, the
corresponding RDAP-RDDS service will be considered as unavailable from that
probe until it is time to make a new test.
4.3. Collating
the results from RDAP-RDDS probes. The minimum number of active testing
working RDAP-RDDS 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.4. Placement
of RDAP-RDDS probes. ICANN will use commercially reasonable efforts
to deploy probes
for measuring RDAP parameters in data centers with carrier grade connectivity
in each of the ICANN geographic regions.
4.5. 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 Appendix as it would to any other request from an Internet
user for RDAP.
4.6. Emergency
Escalation. Registry Operator and ICANN shall provide the contact
information of their respective emergency operations departments to the other
party for the purposes of this Section and such contact information shall be
maintained and kept current at all times by both Registry Operator and ICANN.
ICANN shall issue an emergency escalation notice informing Registry Operator of
any possible or potential issues in relation to the monitored RDAP-RDDS
service. Upon the issuance of an emergency escalation notice, Registry Operator
and ICANN shall cooperate and use commercially reasonable efforts to diagnose
and/or resolve the identified issue(s), including through the sharing of
appropriate measurement data. The initiation of any emergency escalation and
the subsequent cooperation to diagnose and/or resolve the identified issue(s)
do not in themselves imply or otherwise establish that the monitored RDAP-RDDS
service has failed the applicable Service Level Requirements set forth in
Section 3.1 above.
5. ICANN reserves the
right to specify alternative formats and protocols approved as “Internet
Standards” (as opposed to Informational or Experimental standards) through the
applicable IETF processes with respect to registration data referenced in
Appendix 5A and Appendix 5B. Upon such specification, ICANN shall: (a) work
collaboratively with Registry Operator and other gTLD registries and
ICANN-accredited registrars to define all operational requirements necessary to
implement the applicable standard; and (b) if applicable, initiate negotiations
with Registry Operator to define all reporting requirements (if any), and
reasonable service level requirements commensurate with similarly situated
services and as applicable to the TLD.
.com
Registry Agreement Appendix 6
Schedule of Reserved Names
Except
to the extent that ICANN otherwise expressly authorizes in writing, the
Registry Operator shall reserve names formed with the following labels from
initial (i.e. other than renewal) registration within the TLD:
A.
Labels Reserved at All Levels. The following names shall be
reserved at the second level and at all other levels within the TLD at which
Registry Operator makes registrations:
ICANN-related
names:
- aso
- gnso
- icann
- internic
- ccnso
IANA-related
names:
- afrinic
- apnic
- arin
- example
- gtld-servers
- iab
- iana
- iana-servers
- iesg
- ietf
- irtf
- istf
- lacnic
- latnic
- rfc-editor
- ripe
- root-servers
B.
Additional Second-Level Reservations. In addition, the following
names shall be reserved at the second level:
- All single-character labels. Notwithstanding this reservation
the single-character label o.com may be released pursuant to the o.com
Service (defined in Appendix 7, Section 8.2).
- All two-character labels shall be initially reserved. The
reservation of a two-character label string shall be released to the
extent that the Registry Operator reaches agreement with the government
and country-code manager, or the ISO 3166 maintenance agency, whichever
appropriate. The Registry Operator may also propose release of these
reservations based on its implementation of measures to avoid confusion
with the corresponding country codes.
C.
Tagged Domain Names. All labels with hyphens in the third and fourth character
positions (e.g., "bq--1k2n4h4b" or "xn--ndk061n")
D.
Second-Level Reservations for Registry Operations. The
following names are reserved for use in connection with the operation of the
registry for the Registry TLD. They may be used by Registry Operator, but upon
conclusion of Registry Operator's designation as operator of the registry for
the Registry TLD they shall be transferred as specified by ICANN:
.com Registry Agreement Appendix 7
Functional and Performance Specifications
These
functional specifications for the Registry TLD consist of the following parts:
1.
Registry Operator Registrar Protocol;
2.
Supported initial and renewal registration periods;
3.
Grace period policy;
4.
Nameserver functional specifications;
5.
Patch, update, and upgrade policy;
6.
Performance Specifications;
7.
Responsibilities of the Parties;
8.
Additional Services; and
9.
Implementation of New Standards
1.
Registry Operator Registrar Protocol
1.1
Extensible Provisioning Protocol
Registry
Operator shall maintain the Extensible Provisioning Protocol ("EPP")
in conformance with the Proposed Standard and Informational RFCs 5730, 5731,
5732, 5734, 5910, and 3915 (and in the event Registry Operator accepts thick
registration data RFC 5733) published by the Internet Engineering Task Force
("IETF") and/or any successor standards, versions, modifications or
additions thereto as Registry Operator deems reasonably necessary. Registry
Operator will support EPP in conformance with the aforementioned standards. If
Registry Operator requires the use of functionality outside of EPP RFCs,
Registry Operator must document EPP extensions using Internet-Draft format
following the guidelines described in RFC 3735. Registry Operator is not
required to submit documented EPP extensions to the IETF but to consider the
recommendations on standardization described in section 2.1 of RFC 3735.
Registry Operator will provide and update the relevant documentation of all the
EPP objects and Extensions supported to ICANN prior to deployment.
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 its Shared Registration System (SRS) to any Registrar, no later
than six months after receiving the first request in writing from a gTLD
accredited Registrar willing to operate the SRS over IPv6.
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.
2. Supported initial and renewal registration periods
2.1.
Initial registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry
for terms of up to ten years.
2.2.
Renewal registrations of Registered Names (where available according to
functional specifications and other requirements) may be made in the registry
for terms not to exceed a total of ten years.
2.3.
Upon change of sponsorship of the registration of a Registered Name from one
Registrar to another, according to Part A of the ICANN Policy on Transfer of
Registrations between Registrars, the term of registration of the Registered
Name shall be extended by one year, provided that the maximum term of the
registration as of the effective date of sponsorship change shall not exceed
ten years.
2.4.
The change of sponsorship of registration of Registered Names from one
Registrar to another, according to Part B of the ICANN Policy on Transfer of
Registrations between Registrars shall not result in the extension of the term
of the registrations and Registry Operator may assist in such change of
sponsorship.
3.
Grace period policy
This
section describes Registry Operator's practices for operational
"Grace" and "Pending" periods, including relationships
among sequential operations that occur within given time frames. A Grace
Period refers to a specified number of calendar days following a Registry
operation in which a domain action may be reversed and a credit may be issued
to a Registrar. Relevant registry operations in this context are:
·
Registration of a new domain,
·
Renewal of an existing domain,
·
Auto-Renew of an existing domain;
·
Transfer of an existing domain; and
·
Deletion of an existing domain.
Extension
of a registration period is accomplished using the EPP RENEW command or by
auto-renewal; registration is accomplished using the EPP CREATE command;
deletion/removal is accomplished using the EPP DELETE command; transfer is
accomplished using the EPP TRANSFER command or, where ICANN approves a bulk
transfer under Part B of the ICANN Policy on Transfer of Registrations between
Registrars, using the procedures specified in that Part. Restore is
accomplished using the EPP UPDATE command.
There
are five grace periods provided by Registry Operator's Shared Registration
System: Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace
Period, Transfer Grace Period, and Redemption Grace Period.
A Pending
Period refers to a specified number of calendar days following a Registry
operation in which final Registry action is deferred before the operation may
be completed. Relevant Registry operations in this context are:
·
Transfer of an existing domain,
·
Deletion of an existing domain, and
·
Restoration of a domain name in Redemption Grace Period.
3.1.
Grace Periods
3.1.1
Add Grace Period
The Add
Grace Period is a specified number of calendar days following the initial
registration of a domain. The current value of the Add Grace Period for
all Registrars is five calendar days. If a Delete, Extend (EPP Renew command),
or Transfer operation occurs within the five calendar days, the following rules
apply:
Delete. If a
domain is deleted within the Add Grace Period, the sponsoring Registrar
at the time of the deletion is credited for the amount of the registration;
provided, however, that Registry Operator shall have the right to charge
Registrars a fee as may be set forth in its Registry-Registrar Agreement for disproportionate
deletes during the Add Grace Period. The domain is deleted from the
Registry database and is immediately available for registration by any
Registrar. See Section 3.2 for a description of overlapping grace period
exceptions.
Extend
(EPP Renew command). If a domain is extended within the Add Grace Period, there
is no credit for the add. The expiration date of the domain registration is
extended by the number of years, up to a total of ten years, as specified by
the Registrar's requested Extend operation.
Transfer
(other than ICANN-approved bulk transfer). Transfers under Part A
of the ICANN Policy on Transfer of Registrations between Registrars may not
occur during the Add Grace Period or at any other time within the first
60 days after the initial registration. Enforcement is the responsibility of
the Registrar sponsoring the domain name registration and is enforced by the
SRS.
Bulk
Transfer (with ICANN approval). Bulk transfers with ICANN
approval may be made during the Add Grace Period according to the
procedures in Part B of the ICANN Policy on Transfer of Registrations between
Registrars. The expiration dates of transferred registrations are not affected.
The losing Registrar's account is charged for the initial add.
3.1.2.
Renew/Extend Grace Period
The Renew/Extend
Grace Period is a specified number of calendar days following the
renewal/extension of a domain name registration period through an EPP Command
Renew. The current value of the Renew/Extend Grace Period is five
calendar days. If a Delete, Extend, or Transfer occurs within that five
calendar days, the following rules apply:
Delete. If a
domain is deleted within the Renew/Extend Grace Period, the sponsoring
Registrar at the time of the deletion receives a credit of the renew/extend
fee. The domain immediately goes into the Redemption Grace Period. See Section
3.2 for a description of overlapping grace period exceptions.
Extend
("EPP Command 'Renew'"). A domain can be extended
within the Renew/Extend Grace Period for up to a total of ten years. The
account of the sponsoring Registrar at the time of the additional extension
will be charged for the additional number of years the registration is
extended.
Transfer
(other than ICANN-approved bulk transfer). If a domain is
transferred within the Renew/Extend Grace Period, there is no credit.
The expiration date of the domain registration is extended by one year and the
years added as a result of the Extend remain on the domain name up to a total
of 10 years.
Bulk
Transfer (with ICANN approval). Bulk transfers with ICANN approval may be made
during the Renew/Extend Grace Period according to the procedures in Part
B of the ICANN Policy on Transfer of Registrations between Registrars. The
expiration dates of transferred registrations are not affected. The losing
Registrar's account is charged for the Renew/Extend operation.
3.1.3.
Auto-Renew Grace Period
The Auto-Renew
Grace Period is a specified number of calendar days following an
auto-renewal. An auto-renewal occurs if a domain name registration is not
renewed by the expiration date; in this circumstance the registration will be
automatically renewed by the system the first day after the expiration date.
The current value of the Auto-Renew Grace Period is 45 calendar days. If
a Delete, Extend, or Transfer occurs within the Auto-Renew Grace Period,
the following rules apply:
Delete. If a
domain is deleted within the Auto-Renew Grace Period, the sponsoring
Registrar at the time of the deletion receives a credit of the Auto-Renew fee.
The domain immediately goes into the Redemption Grace Period. See Section 3.2
for a description of overlapping grace period exceptions.
Extend. A
domain can be extended within the Auto-Renew Grace Period for up to a
total of ten years. The account of the sponsoring Registrar at the time of the
additional extension will be charged for the additional number of years the
registration is extended.
Transfer
(other than ICANN-approved bulk transfer). If a domain is
transferred within the Auto-Renew Grace Period, the losing Registrar is
credited with the Auto-Renew charge and the year added by the Auto-Renew
operation is cancelled. The expiration date of the domain is extended by one
year up to a total maximum of ten and the gaining Registrar is charged for that
additional year, even in cases where a full year is not added because of the
10-year registration term maximum limitation.
Bulk
Transfer (with ICANN approval). Bulk transfers with ICANN
approval may be made during the Auto-Renew Grace Period according to the
procedures in Part B of the ICANN Policy on Transfer of Registrations between
Registrars. The expiration dates of transferred registrations are not affected.
The losing Registrar's account is charged for the Auto-Renew.
3.1.4.
Transfer Grace Period
The Transfer
Grace Period is a specified number of calendar days following the transfer
of a domain according to Part A of the ICANN Policy on Transfer of
Registrations between Registrars. The current value of the Transfer Grace
Period is five calendar days. If a Delete, Extend, or Transfer occurs
within that five calendar days, the following rules apply:
Delete. If a
domain is deleted within the Transfer Grace Period, the sponsoring
Registrar at the time of the deletion receives a credit of the transfer fee.
The domain immediately goes into the Redemption Grace Period. See Section 3.2
for a description of overlapping grace period exceptions.
Extend. If a
domain registration is extended within the Transfer Grace Period, there
is no credit for the transfer. The Registrar's account will be charged for the
number of years the registration is extended. The expiration date of the domain
registration is extended by the number of years, up to a maximum of ten years,
as specified by the Registrar's requested Extend operation.
Transfer
(other than ICANN-approved bulk transfer). If a domain is
transferred within the Transfer Grace Period, there is no credit. The
expiration date of the domain registration is extended by one year up to a
maximum term of ten years. The ICANN Policy on Transfer of Registrations
between Registrars does not allow transfers within the first 60 days after
another transfer has occurred; it is the Registrar's responsibility to enforce
this restriction.
Bulk
Transfer (with ICANN approval). Bulk transfers with ICANN
approval may be made during the Transfer Grace Period according to the
procedures in Part B of the ICANN Policy on Transfer of Registrations between
Registrars. The expiration dates of transferred registrations are not affected.
The losing Registrar's account is charged for the Transfer operation that occurred
prior to the Bulk Transfer.
3.1.5.
Bulk Transfer Grace Period
There
is no grace period associated with Bulk Transfer operations. Upon completion of
the Bulk Transfer, any associated fee is not refundable.
3.1.6
Redemption Grace Period
A
domain name is placed in REDEMPTIONPERIOD status when a Registrar requests the
deletion of a domain that is not within the Add Grace Period. A name that is in
REDEMPTIONPERIOD status will not be included in the zone file. A Registrar
cannot modify or purge a domain in REDEMPTIONPERIOD status. The only action a
Registrar can take on a domain in REDEMPTIONPERIOD is to request that it be
restored. Any other Registrar requests to modify or otherwise update the domain
will be rejected. Unless restored, the domain will be held in REDEMPTIONPERIOD
status for a specified number of calendar days. The current length of this
Redemption Period is 30 calendar days.
3.2.
Overlapping Grace Periods
If an
operation is performed that falls into more than one grace period, the actions
appropriate for each grace period apply (with some exceptions as noted below).
·
If a domain is deleted within the Add Grace Period and the Extend
Grace Period, then the Registrar is credited the registration and extend
amounts, taking into account the number of years for which the registration and
extend were done.
·
If a domain is auto-renewed, then extended, and then deleted
within the Extend Grace Period, the Registrar will be credited for any
Auto-Renew fee charged and the number of years for the extension.
3.2.1.
Overlap Exception
·
If a domain registration is extended within the Transfer Grace
Period, then the current Registrar's account is charged for the number of years
the registration is extended.
Note: If
several billable operations, including a transfer, are performed on a domain
and the domain is deleted within the grace periods of each of those operations,
only those operations that were performed after the latest transfer, including
the latest transfer, are credited to the current Registrar.
3.3.
Pending Periods
3.3.1.
Transfer Pending Period
The Transfer
Pending Period is a specified number of calendar days following a request
from a Registrar (Registrar A) to transfer a domain in which the current
Registrar of the domain (Registrar B) may explicitly approve or reject the
transfer request. The current value of the Transfer Pending Period is
five calendar days for all Registrars. The transfer will be finalized upon
receipt of explicit approval or rejection from the current Registrar (Registrar
B). If the current Registrar (Registrar B) does not explicitly approve or
reject the request initiated by Registrar A, the Registry Operator will approve
the request automatically after the end of the Transfer Pending Period.
During the Transfer Pending Period:
a. EPP
TRANSFER request or EPP RENEW request is denied.
b. SYNC is not allowed.
c. EPP DELETE request is denied.
d. Bulk Transfer operations are allowed.
e. EPP UPDATE request is denied.
After
a transfer of a domain, the EPP TRANSFER request may be denied for 60 days.
3.3.2.
Pending Delete Period
A
domain name is placed in PENDING DELETE status if it has not been restored
during the Redemption Grace Period. A name that is in PENDING DELETE status
will not be included in the zone file. All Registrar requests to modify or
otherwise update a domain in PENDING DELETE status will be rejected. A domain
name is purged from the registry database a specified number of calendar days
after it is placed in PENDING DELETE status. The current length of this Pending
Delete Period is five calendar days.
4.
Nameserver functional specifications
Nameserver
operations for the Registry TLD shall comply with RFCs 1034, 1035, 1982, 2181,
2182, 2671, 3226, 3596, 3597, 4343, and 5966 published by the Internet
Engineering Task Force ("IETF") and/or any successor standards,
versions, modifications or additions thereto.
Registry
Operator shall sign its TLD zone files implementing Domain Name System Security
Extensions ("DNSSEC"). Registry Operator shall comply with RFCs 4033,
4034, 4035, 4509 and their successors, and the parties agree that best
practices described in RFC 4641 and its successors are recommended but not
mandatory. 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.
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.
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 Operator 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 but this provision shall not apply to the
provision of nameservice or any other non-registry service for a domain or zone
used for other than registration services to unaffiliated third parties by a
single entity (including its affiliates) for domain names registered through an
ICANN-Accredited Registrar.
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
https://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.
5.
Patch, update, and upgrade policy
Registry
Operator may issue periodic patches, updates or upgrades to the Software, EPP
or APIs ("Licensed Product") licensed under the Registry-Registrar
Agreement (the "Agreement") that will enhance functionality or
otherwise improve the Shared Registration System under the Agreement. For the
purposes of this Section 5 of Appendix 7, the following terms have the
associated meanings set forth herein.
5.1 A
"Patch" means minor modifications to the Licensed Product made by
Registry Operator during the performance of error correction services. A Patch
does not constitute a Version.
5.2 An
"Update" means a new release of the Licensed Product which may
contain error corrections, minor enhancements, and, in certain circumstances,
major enhancements, and which is indicated by a change in the digit to right of
the decimal point in the version number of the Licensed Product.
5.3 An
"Upgrade" means a new release of the Licensed Product which involves
the addition of substantial or substantially enhanced functionality and which
is indicated by a change in the digit to the left of the decimal point in the
version of the Licensed Product.
5.4 A
"Version" means the Licensed Product identified by any single version
number.
Each
Update and Upgrade causes a change in version.
* Patches do not require corresponding changes to client applications
developed, implemented, and maintained by each Registrar.
* Updates may require changes to client applications by each Registrar in order
to take advantage of the new features and/or capabilities and continue to have
access to the Shared Registration System.
* Upgrades require changes to client applications by each Registrar in order to
take advantage of the new features and/or capabilities and continue to have
access to the Shared Registration System.
Registry
Operator, in its sole discretion, will deploy Patches during scheduled and
announced Shared Registration System maintenance periods.
For
Updates and Upgrades, Registry Operator will give each Registrar notice prior
to deploying the Updates and Upgrades into the production environment. The
notice shall be at least ninety (90) days. Such notice will include an initial
notice before deploying the Update that requires changes to client applications
or the Upgrade into the Operational Test and Evaluation ("OT&E")
environment to which all Registrars have access. Registry Operator will
maintain the Update or Upgrade in the OT&E environment for at least thirty
(30) days, to allow each Registrar the opportunity to modify its client
applications and complete testing, before implementing the new code in the
production environment.
This
notice period shall not apply in the event Registry Operator's system is
subject to the imminent threat of a failure or a material security threat, the
discovery of a major security vulnerability, or a Denial of Service (DoS)
attack where the Registry Operator's systems are rendered inaccessible by being
subject to:
i)
excessive levels of data traffic
ii) unauthorized traffic
iii) data traffic not conforming to the protocols used by the Registry
6.
Performance Specifications
These
Performance Specifications provide a means to measure Registry Operator's
delivery of SRS, DNS Name Server and Whois services for the Registry TLD and
serve as the basis for the Service Level Agreements Credits ("SLA
Credits") set forth in Appendix 10.
6.1
Definitions. Capitalized terms used in this Section 6 and not otherwise defined
shall have the meaning ascribed to them in the Registry Agreement.
6.1.1
"Core Internet Service Failure" means an extraordinary
and identifiable event beyond the control of Registry Operator affecting the
Internet services to be measured pursuant to this Section 6. Such events
include, but are not limited to congestion collapse, partitioning, power grid
failures, and routing failures.
6.1.2
"Credit Level" means the credit levels set forth in the
Table SLA Credits in Section 2 of Appendix 10 that outlines the total credits,
penalties and/or liabilities that may be assessed to Registry Operator and sole
remedies available to ICANN-Accredited Registrars for Registry Operators
failure to meet Performance Specifications outlined in this Appendix 7.
6.1.3
"DNS Name Server" means the service complying with RFC
1034, 1035 and related RFCs made available on TCP/UDP port 53 on Registry
Operator's selected servers.
6.1.4
"ICANN-Accredited Registrar" means an ICANN-Accredited
Registrar that has a Registry-Registrar Agreement in effect with Registry
Operator.
6.1.5
"Monthly Timeframe" means each single calendar
month beginning and ending at 0000 Coordinated Universal Time (UTC).
6.1.6
"Performance Specifications" means a description of the
measurable functional attributes of a particular System Services.
6.1.7
"Registrar Community" means all of the
ICANN-Accredited Registrars who have Registry-Registrar Agreements in effect
with Registry Operator for the Registry TLD and who have registered greater
than 150 net new .com domain names in the prior thirty (30) calendar day
period.
6.1.8
"Round-trip" means the amount of measured time that it
takes for a reference query to make a complete trip from the SRS gateway,
through the SRS system, back to the SRS gateway.
6.1.9
"Service Level Agreement (SLA)" means the service
level agreements attached as Appendix 10 to the Registry Agreement outlining
performance standards levels.
6.1.10
"SRS" means the Shared Registration System, a system that the Registry
Operator provides to the Registrar Community via a defined protocol (EPP) for
registry-registrar interaction. Specifically, it refers to the ability of
ICANN-Accredited Registrars to add, modify, and delete (create, update and
delete) information associated with registered domain names and associated DNS
Name Servers.
6.1.11
"System Services" means the SRS, DNS Name Server and Whois
services for the Registry TLD for which availability and Performance
Specifications are established.
6.1.12
"Whois" refers to the Registry Operator's Whois service provided in
accordance with Appendix 5A.
6.2
Service Availability. Service availability is defined as the
time, in minutes, that the Registry Operator's System Services are each
individually responding to its users ("Service Availability")
as further defined in Sections 6.2.1 through 6.2.4.
6.2.1
Service Availability is measured as follows:
Service
Availability % = {[(MTM - POMU) - UOM] / (MTM - POMU)}*100 where:
MTM =
Monthly Timeframe Minutes calculated as the number days in that month times 24
hours times 60 minutes. For example, the MTM for January is 31 days * 24 hours
* 60 minutes or MTM = 44,640 minutes.
POMU =
Planned Outage Minutes Used equals the number of minutes of a Planned Outage
(as defined in Section 6.3 below) or Extended Planned Outage (as defined in
Section 6.4 below) for that Monthly Timeframe for each individual System
Service. No Monthly Timeframe shall have both a Planned and an Extended Planned
Outage.
UOM =
Unplanned Outage Minutes equals the total number of minutes the System Services
is unavailable excluding any Planned Outages (as defined in Section 6.3 below)
or Extended Planned Outage (as defined in Section 6.4 below) for that Monthly
Timeframe.
The
Service Availability calculation shall be calculated by the Registry Operator
and the results reported for each Monthly Timeframe for SRS, Whois and DNS Name
Server availability. For Service Availability Performance Specifications
measured by calendar year, Yearly Timeframe Minutes (YTM) shall be substituted
for Monthly Timeframe Minutes (MTM) in the calculation above. Yearly Timeframe
Minutes calculated as 365 days * 24 hours * 60 minutes = 525,600 minutes.
Results will be reported to the Registrar Community via e-mail and to ICANN
according to Appendix 4.
6.2.2
Service Availability--SRS = 99.99% per calendar year. Service
Availability as it applies to the SRS refers to the ability of the SRS to
respond to ICANN-Accredited Registrars that access the SRS through the EPP
protocol. SRS unavailability, except for Planned Outages (as defined in Section
6.3 below) and Extended Planned Outages (as defined in Section 6.4 below), will
be logged with the Registry Operator as Unplanned Outage Minutes.
Unavailability will not include any events affecting individual ICANN-Accredited
Registrars locally.
SRS
unavailability as it applies to the SRS shall mean when, as a result of a
failure of systems within the Registry's control, an ICANN-Accredited Registrar
is unable to establish a session with the SRS gateway; provided, however, that
SRS unavailability shall not include an ICANN-Accredited Registrar's inability
to establish a session with the SRS gateway that results from it exceeding its
designated number of sessions. Establishing a session with the SRS gateway
shall be defined as:
a)
successfully complete a TCP session start,
b)
successfully complete the SSL or TLS authentication handshake, and
c)
successfully complete the Extensible Provisioning Protocol (EPP) login command.
Registry
Operator will log SRS unavailability once an ICANN-Accredited Registrar reports
an occurrence to Registry Operator's customer service help desk in the manner
required by the Registry Operator (i.e., e-mail, fax, telephone). The committed
Service Availability for SRS is 99.99% per calendar year. The SRS Service
Availability metric is a Credit Level 2.
6.2.3
Service Availability--DNS Name Server = 100% per Monthly Timeframe. Service
Availability as it applies to the DNS Name Server refers to the ability of the
DNS Name Server to resolve a DNS query from an Internet user. DNS Name Server
unavailability will be logged with the Registry Operator as Unplanned Outage
Minutes. Registry Operator will log DNS Name Server unavailability (a) when
such unavailability is detected by monitoring tools, or (b) once an
ICANN-Accredited Registrar reports an occurrence to Registry Operator's
customer service help desk in the manner required by the Registry Operator
(i.e., e-mail, fax, telephone) and Registry Operator confirms that the
occurrence is not unique to the reporting Registrar.
DNS
Name Server unavailability shall mean less than eight (8) sites on the Registry
Operator's constellation are returning answers to queries with less than 1%
packet loss averaged over a Monthly Timeframe or 5% packet loss for any five
minute period.
The
committed Service Availability for DNS Name Server is 100% per Monthly
Timeframe. The DNS Name Server Service Availability metric is a Credit Level 1.
6.2.4
Service Availability--Whois = 100% per Monthly Timeframe. Service
Availability as it applies to Whois refers to the ability of Internet users to
access and use the Whois. Whois unavailability, except for Planned Outages (as
defined in Section 6.3 below) and Extended Planned Outages (as defined in
Section 6.4 below), will be logged with the Registry Operator as Unplanned
Outage Minutes. Registry Operator will log Whois unavailability (a) when such
unavailability is detected by Registry Operator's monitoring tools, or (b) once
an ICANN-Accredited Registrar reports an occurrence to Registry Operator's
customer service help desk in the manner required by the Registry Operator
(i.e., e-mail, fax, telephone). The committed Service Availability for Whois is
100% per Monthly Timeframe. The Whois Service Availability metric is a Credit
Level 2.
6.3
Planned Outage. From time to time the Registry Operator will require an outage for
regular maintenance or the addition of new functions or features ("Planned
Outage").
6.3.1
Planned Outage Duration. Planned Outage duration defines the
maximum allowable time, in minutes, that the Registry Operator is permitted to
take the System Services out of service for regularly scheduled maintenance
("Planned Outage Duration"). Planned Outages are planned in
advance and the Registrar Community is provided notification prior to an
outage.
The
Planned Outage Duration for the System Services is as follows:
(i)
Planned Outage Duration - SRS = 45 minutes per Monthly Timeframe;
(ii)
Planned Outage Duration - DNS Name Server = no Planned Outages allowed; and
(iii)
Planned Outage Duration - Whois = no Planned Outages allowed.
The
Planned Outage Duration metric is a Credit Level 6.
6.3.2
Planned Outage Timeframe. The Planned Outage Timeframe defines the
hours and days in which a Planned Outage may occur ("Planned Outage
Timeframe"). The Planned Outage Timeframe for the System Services is
as follows:
(i)
Planned Outage Timeframe - SRS = 0100-0900 UTC Sunday;
(ii)
Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and
(iii)
Planned Outage Timeframe - Whois = no Planned Outages allowed.
The
Planned Outage Timeframe metric is a Credit Level 5.
6.3.3
Planned Outage Notification. The Registry Operator shall
notify all ICANN-Accredited Registrars of any Planned Outage ("Planned
Outage Notification"). The Planned Outage Notification shall set forth
the date and time of the Planned Outage. The number of days prior to a Planned
Outage that the Registry Operator shall notify the Registrar Community is as
follows:
(i)
Planned Outage Timeframe - SRS = 30 days for general maintenance and 90 days
for Updates or Upgrades as defined in the Patch, Update and Upgrade Policy in
Section 5 of this Appendix 7;
(ii)
Planned Outage Timeframe - DNS Name Server = no Planned Outages allowed; and
(iii)
Planned Outage Timeframe - Whois = no Planned Outages allowed.
The
Planned Outage Notification metric is a Credit Level 5.
6.4
Extended Planned Outage. In some cases, such as major software
upgrades and platform replacements, an extended maintenance timeframe is
required ("Extended Planned Outage"). Extended Planned Outages
will be less frequent than Planned Outages but their duration may be longer.
6.4.1
Extended Planned Outage Duration. The Extended Planned Outage
duration defines the maximum allowable time, in hours and minutes that the
Registry Operator is permitted to take the System Services out of service for
extended maintenance ("Extended Planned Outage Duration").
Extended Planned Outages are planned in advance and the Registrar Community is
provided notification in accordance with Section 6.4.3. Extended Planned Outage
periods may not occur in the same Monthly Timeframe as a Planned Outage. The
Extended Planned Outage Duration for the System Services is as follows:
(i)
Extended Planned Outage Duration - SRS = 4 hours (240 minutes) per calendar
year and one Extend Planned Outage of 8 hours (480) minutes every 3 years;
(ii)
Extended Planned Outage Duration - DNS Name Server = no Extended Planned
Outages allowed; and
(iii)
Extended Planned Outage Duration - Whois = no Extended Planned Outages allowed.
The
Extended Planned Outage Duration metric is a Credit Level 6.
6.4.2
Extended Planned Outage Timeframe. The Extended Planned Outage
Timeframe defines the hours and days in which the Extended Planned Outage may
occur ("Extended Planned Outage Timeframe"). The Extended
Planned Outage Timeframe for the System Services is as follows:
(i)
Extended Planned Outage Timeframe - SRS = 0100 - 1300 UTC Sunday;
(ii)
Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned
Outages allowed; and
(iii)
Extended Planned Outage Timeframe - Whois = no Extended Planned Outages
allowed.
The
Extended Planned Outage Timeframe metric is a Credit Level 5.
6.4.3
Extended Planned Outage Notification. The Registry Operator must
notify the Registrar Community of any Extended Planned Outage ("Extended
Planned Outage Notification"). The Extended Planned Outage
Notification shall set forth the date and time of the Extended Planned Outage.
The number of days prior to an Extended Planned Outage that the Registry
Operator must notify ICANN-Accredited Registrars is as follows:
(i)
Extended Planned Outage Timeframe - SRS = 90 Days;
(ii)
Extended Planned Outage Timeframe - DNS Name Server = no Extended Planned
Outages allowed; and
(iii)
Extended Planned Outage Timeframe - Whois = no Extended Planned Outages
allowed.
The
Extended Planned Outage Notification metric is a Credit Level 5.
6.5
Processing Time. Processing time is a measurement of Service Availability and
equals the Round-trip for the System Services ("Processing Time").
The Registry Operator will log the Processing Time for all of the protocol
transactions (i.e. Check, Add/Create, Modify/Update and Delete). Processing
Time will be measured in a Monthly Timeframe and reported on a monthly basis to
ICANN in accordance with Appendix 4. Should the total volume of protocol
transactions (measured individually) added by all ICANN-Accredited Registrars
for a Monthly Timeframe exceed Registry Operator's actual volume of protocol
transactions for the previous Monthly Timeframe by more than 20%, then
ICANN-Accredited Registrars shall not be eligible for any SLA credit, and
Registry Operator shall have no liability to ICANN, if Registry Operator fails
to meet a Processing Time Performance Specification set forth in this Section
6.5.
6.5.1
Processing Time--Check Domain = 25 milliseconds for 95%.
(i)
The Processing Time for Check Domain is applicable to the SRS as accessed
through the defined protocol (EPP) for registry-registrar interaction and
measures the Processing Time for an availability check of a specific domain
name.
(ii)
The performance specification for Check Domain is 25 milliseconds Round-trip
for 95% of the transactions during a Monthly Timeframe.
The
Processing Time for Check Domain metric is a Credit Level 3.
6.5.2
Processing Time--Add/Create = 50 milliseconds for 95%.
(i)
The Processing Time for Add/Create is applicable to the SRS as accessed through
the defined protocol (EPP) for registry-registrar interaction and measures the
Processing Time for add/create transactions associated with domain names.
(ii)
The Performance Specification for Add/Create is 50 milliseconds for Round-trip
for 95% of the transactions processed during a Monthly Timeframe.
The
Processing Time for Add/Create metric is a Credit Level 3.
6.5.3 Processing
Time--Modify/Update and Delete Domain = 100 milliseconds for 95%.
(i)
The Processing Time for Modify/Update and Delete is applicable to the SRS as
accessed through the defined protocol (EPP) for registry-registrar interaction
and measures the Processing Time for Modify/Update and Delete transactions
associated with domain names.
(ii)
The Performance Specification for Modify/Update and Delete is 100 milliseconds
Round-trip for 95% of the transactions processed during a Monthly Timeframe.
The
Processing Time for Modify/Update and Delete metric is a Credit Level 3.
6.5.4
Processing Time--Whois Query = 5 milliseconds for 95%.
(i)
The Processing Time for Whois query is applicable to the Whois and measures the
Processing Time for a Whois query.
(ii)
The Performance Specification for a Whois query is 5 milliseconds for 95% of
the transactions during a Monthly Timeframes. That is, 95% of the transactions
during a Monthly Timeframe will take 5 milliseconds or less from the time the
Whois receives a query to the time it responds.
The
Processing Time for Whois Query metric is a Credit Level 3.
6.5.5
Processing Time--DNS Name Server Resolution = 100 milliseconds for 95%.
(i)
The Processing Time for DNS Name Server Resolution is applicable to the DNS
Name Server and measures the processing time for a DNS query.
(ii)
The Performance Specification for DNS Name Server Resolution is 100
milliseconds for 95% of the transactions during a Monthly Timeframe. That is,
95% of the transactions during a Monthly Timeframe will take 100 milliseconds
or less from the time the name server receives the DNS query to the time it
provides a response.
The
Processing Time for the DNS Name Server metric is a Credit Level 3.
6.6
Update Frequency. The Registry Operator makes timely updates to the data on the DNS
Name Servers and Whois. ICANN-Accredited Registrars record these updates
through the SRS. The SRS then updates the DNS Name Server and the Whois.
Registry Operator processes these updates on a near real time basis.
The
committed performance specification with regards to Update frequency for both
the DNS Name Server and the Whois is 3 minutes for 95% of the transactions
during a Monthly Timeframe. That is, 95% of the updates to the DNS Name Servers
and Whois during a Monthly Timeframe will be completed within 3 minutes. Update
frequency is measured from the time that the Registry Operator confirms the
update to the time the update appears in the DNS Name Server and Whois. Update
frequency performance will be reported on a monthly basis to ICANN in
accordance with Appendix 4.
6.6.1
Update Frequency--DNS Name Server = 3 minutes for 95% during a Monthly
Timeframe.
The
Update frequency--DNS Name Server is 3 minutes for 95% during a Monthly
Timeframe.
The
Update frequency metric for DNS Name Server is Credit Level 4.
6.6.2
Update Frequency--Whois - 3 minutes for 95% during a Monthly Timeframe.
The
Update frequency--Whois is 3 minutes for 95% during a Monthly Timeframe.
The
Update frequency metric for Whois is Credit Level 4.
6.7
Cross-Network Name Server Performance Requirements. DNS
Name Server Round-trip and packet loss from the Internet are important elements
of the quality of service provided by the Registry Operator. These
characteristics, however, are affected by Internet performance and, therefore,
cannot be closely controlled by Registry Operator. Accordingly, these
requirements are not matters subject to SLA Credits under the Service Level
Agreement set forth on Appendix 10 or obligations upon which a breach by
Registry Operator of the Registry Agreement may be asserted.
The
committed performance specification for cross-network name server performance
is a measured Round-trip of under 300 milliseconds and measured packet loss of
under 1% averaged over the course of a Monthly Timeframe and no greater than 5%
for any five (5) minute period over the course of the Monthly Timeframe.
Cross-network name server performance measurements may be conducted by ICANN at
the times of its choosing, in the following manner:
6.7.1
The measurements may be conducted by sending strings of DNS request packets
from different measuring locations to each of the .com DNS Name Servers and
observing the responses from the .com DNS Name Servers. (These strings of
requests and responses are referred to as a "CNNP Test".) The
measuring locations will be distributed around the Internet.
6.7.2
Each string of request packets will consist of UDP or TCP packets requesting
nameserver (NS) records for arbitrarily selected .com second-level domains,
preselected to ensure that the names exist in the Registry TLD and are
resolvable. The packet loss (i.e. the percentage of response packets not
received) and the average Round-trip time for response packets received may be
noted.
6.7.3
To meet the packet loss and Round-trip requirements for a particular CNNP Test,
all three of the following must be true:
6.7.3.1
The Round-trip and packet loss from each measurement location to at least one
.com name server must not exceed the required values;
6.7.3.2
The packet loss to each of the .com name servers from at least one of the
measurement locations must not exceed the required value; and
6.7.3.3
Any failing CNNP Test result obtained during an identified Core Internet
Service Failure shall not be considered.
6.7.4
To ensure a properly diverse testing sample, ICANN will conduct the CNNP Tests
at varying times (i.e. at different times of the day, as well as on different
days of the week). Registry Operator may only be deemed to have persistently
failed to meet the cross-network name server performance requirement only if
the .com DNS Name Servers fail the CNNP Tests (see Section 6.7.3 above) with no
less than three consecutive failed CNNP Tests.
6.7.5
In the event of persistent failure of the CNNP Tests, ICANN will give Registry
Operator written notice of the failures (with backup data) and Registry
Operator will have sixty days to cure the failure.
6.7.6
Sixty days prior to the commencement of testing under this provision, ICANN
will provide Registry Operator with the opportunity to evaluate the testing tools,
measuring locations and procedures to be used by ICANN. In the event that
Registry Operator does not approve of such tools and procedures, ICANN will
work directly with Registry Operator to make necessary modifications.
7.
Responsibilities of the Parties.
7.1
Except in the case of DNS Name Server performance measurements, Registry
Operator will perform monitoring from internally located systems as a means to
verify that the availability and performance measurements in this document are
being met.
7.2
The Registry Operator will provide system performance and availability reports
monthly to the Registrar Community via e-mail and to ICANN according to
Appendix 4.
7.3
The Registry Operator will provide the Whois Service as specified in Appendix
5A.
7.4
The Registry Operator will use commercially reasonable efforts to restore the
critical systems of the System Services within 24 hours after the termination
of a force majeure event and restore full system functionality within 48 hours
after the termination of a force majeure event. Outages due to a force majeure
will not be considered service unavailability for purposes of this Appendix 7
or the SLA.
7.5
Registry Operator shall not be liable to ICANN or ICANN-Accredited Registrars
for any credits or penalties or be deemed to be in breach of any of its
obligations under the Registry Agreement if it fails to meet a Performance
Specification as a result of its compliance with any Consensus Policy
established after the Effective Date to the extent and for so long as the
failure to meet a Performance Specification is unavoidable by commercially
reasonable efforts due to Registry Operator's compliance with such Consensus
Policy.
7.6
Registry Operator shall provide to ICANN and publish on its website its
accurate contact details including a valid email address or webform and mailing
address as well as a primary contact for handling reports related to malicious
conduct in the TLD, including DNS Abuse, as defined in Appendix 11, Section (c)
(Public Interest Commitments), and will provide ICANN with prompt notice of any
changes to such contact details. Upon receipt of such reports, Registry
Operator shall provide the reporter with confirmation that it has received the
report.
8.
Additional Services
8.1
Bulk Transfer After Partial Portfolio Acquisition (BTAPPA)
Bulk
Transfer After Partial Portfolio Acquisition (BTAPPA) is a Registry service
available to consenting Registrars in the circumstance where one
ICANN-Accredited Registrar purchases, by means of a stock or asset purchase,
merger or similar transaction, a portion but not all, of another
ICANN-Accredited Registrar's domain name portfolio in the .com top-level
domain.
At
least fifteen days before completing a BTAPPA, the losing Registrar must
provide to all domain name registrants for names involved in the bulk transfer,
written notice of the bulk change of sponsorship. The notice must include an
explanation of how the Whois record will change after the bulk transfer occurs,
and customer support and technical contact information of the gaining
Registrar.
If a
domain is transferred under the BTAPPA service during any applicable Grace
Period as described in Section 3 above, there is no credit. The expiration
dates of transferred registrations are not affected.
Domain
names in the following statuses at the time of the Transfer Request will not be
transferred in a BTAPPA: "pending transfer", "redemption grace
period (RGP)", or "pending delete". Domain names that are within
the auto-renew grace window are subject to bulk transfer, but Verisign may
decline to provide a credit for those names deleted after the bulk transfer,
but prior to the expiration of the auto-renew grace window.
Verisign
has discretion to reject a BTAPPA request if there is reasonable evidence that
a transfer under BTAPPA is being requested in order to avoid fees otherwise due
to Verisign or ICANN, or if a Registrar with common ownership or management or
both has already requested BTAPPA service within the preceding six-month
period.
8.2 Registration of one .com Domain
Name with a Single-Character Label. Registry Operator may allocate the
single-character label o.com in accordance with the o.com Service Description
attached as Schedule 1 to this Appendix 7 and the following specific conditions
(the “o.com Service”):
(i)
Registry Operator shall
not, directly or indirectly, receive any proceeds from the sale, allocation,
transfer or renewal of o.com and will only receive the standard registry fee
for the registration of o.com, in accordance with the Maximum Price set forth
in Section 7.3(d) of the Agreement.
(ii)
Notwithstanding Appendix
7, Section 3.1.1 (Add Grace Period) of the Agreement, o.com shall not have an
Add Grace Period.
(iii)
Notwithstanding Appendix
7, Section 3.1.2 (Renew/Extend Grace Period) of the Agreement, o.com will not
have a Renewal Grace Period up to and including the twenty-fifth year the
winning registrant renews o.com (if applicable). Beginning on the twenty-sixth
year the winning registrant renews o.com and thereafter (if applicable) a
Renewal Grace Period will apply to o.com.
(iv)
Notwithstanding Appendix
7, Section 3.1.3 (Auto-Renew Grace Period) of the Agreement, o.com will be
automatically renewed under the Auto-Renew Grace Period, each for a single year
period.
(v)
Notwithstanding Appendix 7,
Section 3.3.2 (Pending Delete Period) of the Agreement, o.com shall not be
included on the .com registry’s Pending Delete Report if deleted, and will be
held by Registry Operator until Registry Operator makes o.com available via a
later auction or other allocation process.
9.
Implementation of New Protocols
Registry
Operator and ICANN agree to engage in good faith negotiations at regular
intervals (at least once every eighteen months following the Effective Date)
regarding possible implementation of new RFCs related to the matters addressed
in Appendices 1 (Data Escrow Specification), 5A (Registration Data Publication
Services Specification), 5B (Registration Data Access Protocol Service
Specification) and 7 (Functional and Performance Specifications).
Schedule
1 to Appendix 7
o.com Service Description
o.com Service
Registry Operator will register
o.com (the “SCDN”) in the manner in which it registers other domain
names, with the exceptions set forth below. In addition, the SCDN will be
allocated through an auction managed by a third party auction service provider
selected by Registry Operator. The registration of the SCDN will be allocated
through a pro-competitive and fair auction process and any potential registrant
may participate in the auction process and select any ICANN-accredited
registrar for the management of the SCDN if awarded to their registrant. No
restrictions will be placed on how the registrant may select the .com
ICANN-accredited registrar. Prior to the auction, Registry Operator will
provide registrars with a minimum advanced notice of 60 days as part of its
efforts to notify potential registrants.
Nonprofit Beneficiary
Consistent with its sole role
as service provider and with its lack of any ownership in the SCDN, Registry
Operator will not be paid, nor receive, nor touch any part of the SCDN auction
proceeds. Instead, Registry Operator will only receive the standard registry
fee for the registration of the SCDN, which fee shall be in compliance with
registry fee pricing provisions under Section 7.3(d) of the Agreement for the
registration of any other .com domain name at the time.
Proceeds derived from the
auction of the SCDN will be provided to one or more nonprofit organizations, or
its successors, as set forth in Exhibit A attached hereto and agreed by ICANN
and Registry Operator to be “CONFIDENTIAL” pursuant to Section 3.1(d)(iv)(B) of
the Agreement (“Nonprofit List”). None of the auction proceeds will
directly or indirectly be used to benefit Registry Operator, its affiliates, or
its directors, officers, or employees, other than to the de minimis extent
those proceeds are used by the nonprofit(s) to benefit the Internet community
in general. The nonprofit's, including its successor's, mission will align the
use of funds resulting from the auction of the SCDN toward areas of public good
of the Internet community, which may include one or more of the following:
o
development, evolution, and use of
open Internet protocols
o
enhancing the cybersecurity
readiness and response of public and private sector entities
o
online safety for children
o
improving security, stability and
universal accessibility of the Internet
o
capacity building for the benefit of the Internet
community (such as assisting those
in developing areas
in applying to become registries and registrars)
None of the nonprofit
organizations, including their respective successors, as set forth in the
Nonprofit List, have or will make any contributions, or conduct any activities
directed by, or on behalf of, Registry Operator.
Disbursement of Proceeds to
the Nonprofit Beneficiary
The winning registrant will
submit the auction proceeds to an independent tax-exempt trust that will be set
up by the third party auction service provider (the "Trust").
An independent third party trustee (the "Third Party Trustee")
will (i) select the nonprofit organization(s) to receive the auction proceeds
as outlined above and (ii) manage the receipt and distribution of the auction
proceeds to the nonprofit(s). Registry Operator and its affiliates, directors,
officers, or employees, will not be (i) acting as a trustee of the Trust, (ii)
named in the Trust, or (iii) named as a party to the Trust. The Third Party
Trustee will not conduct any activities directed by, or on behalf of, Registry
Operator except as set forth herein.
Provisioning
Under the o.com Service,
Registry Operator intends for the SCDN to be allocated via an auction. Receipt
of payment in the amount of the winning bid will entitle the registrant to
obtain an initial five (5) year registration. The auction will be managed by a
third party auction service provider selected by Registry Operator. The SCDN
will be allocated through an auction administered by the third party auction
service provider as described below.
The third party auction service provider
will be required to pre-qualify potential registrants for participation in the
auction, which may include asking potential registrants to submit documentation
to the third party auction service provider describing the planned marketing
and usage of the registered domain name, demonstrating the ability to pay, and
additional requirements as may be required by the third party auction service
provider. A team formed by the third party auction service provider will review
and approve the proposals based upon pre-determined qualifications.
The winning registrant must:
(i) submit the entire amount of the winning bid directly to the Trust within
fourteen (14) calendar days from the date on which it was determined to be the
winner (the "First Installment of the Winning Bid"); and (ii)
commit to submitting to the Trust five percent (5%) of the First Installment of
the Winning Bid for each year that the SCDN is renewed after expiration of the
initial five (5) year registration period (each a "Subsequent
Installment") up until, and including, the twenty-fifth (25th) year
the winning registrant renews the SCDN (the "Expiration of the
Subsequent Installment"). The Subsequent Installments are intended to
encourage a continuous funding stream to the nonprofit organization(s) up until
the Expiration of the Subsequent Installment. By way of example, if the auction
took place in 2020 and the winning bid was $10,000, the First Installment of
the Winning Bid for the SCDN would be $10,000 and be paid in 2020, and the Subsequent
Installment for each year after the five (5) year initial term would be $500 and be paid in 2026 through 2045 (i.e., 5% of the First
Installment of the Winning Bid).
In the event a winning
registrant fails to complete the payment transaction within the fourteen (14)
day time period, the: (i) registrant will forfeit its right to register the
SCDN, and (ii) SCDN may be made available to the second highest bidder. This
process will continue until a full payment is received.
Upon completion of the First
Installment of the Winning Bid payment, the third party auction service
provider will issue an authorization code to the winning registrant. The
winning registrant will provide this authorization code to its registrar of
choice. This registrar-of-record for the winning registrant must provide the
authorization code to Registry Operator to complete the initial registration.
The initial term will expire five (5) years from the date of creation. Registry
Operator will charge the registrar the then-applicable registration fee for
each annual increment of a new domain name registration (multiplied by five (5)
increments for a five year term) for the SCDN, which may be paid using its
account associated with the current Verisign System or its Payment Security (as
defined in the .com Registry-Registrar Agreement).
Because Registry Operator is not
processing the payment of any auction proceeds, the registrar-of-record
for the winning registrant will not be permitted to use the account associated
with the current Verisign System or its Payment Security to secure payment of
the winning bid, either in whole or in part.
After registration, the
registrar-of-record will be able to execute any updates for the SCDN requested
by its registrant in the same manner in which all updates are currently
executed.
Should Registry Operator
determine that the winning registrant is not complying with the terms of the
auction agreement executed by the winning registrant to participate in the
auction (the "Auction Agreement"), including failing to
provide to the nonprofit(s) any Subsequent Installments when due, Registry
Operator will have the right to terminate the registration and the SCDN will
enter the standard Redemption Grace Period. The registrar-of-record will be
able to restore the SCDN only if the issue is successfully cured during the
Redemption Grace Period. Following the 5-day Pending Delete period, the SCDN
will be held by the registry for re-auction or other allocation process at a
future date and time.
Following the initial
registration, the specifications of Appendix 7 to the Agreement will apply for
all EPP operations except as otherwise set forth herein or in Appendix 7,
Section 8.2.
The winning registrant may
renew the SCDN for as many years as the Agreement will permit, provided the
winning registrant submits the Subsequent Installment(s) of the Winning Bid to
the Trust up until the Expiration of the Subsequent Installment and standard
registration fees to the registry. Prior to the Expiration of the Subsequent
Installment, in order to renew the SCDN, the winning registrant must submit the
Subsequent Installment of the Winning Bid to the Trust, and following Registry
Operator's receipt of notification from the Third Party Trustee confirming
payment, the registrar-of-record for the SCDN may submit the renewal request to
Registry Operator and will be charged the then-applicable fee for each annual
increment of a new domain name registration. After the Expiration of the
Subsequent Installment, in order to renew the SCDN, the registrar-of-record for
the SCDN will submit the renewal request to Registry Operator and will be
charged the then-applicable fee for each annual increment of a new domain name
registration.
Prior to the Expiration of the
Subsequent Installment, payment of the Subsequent Installment of the Winning
Bid and the then-applicable registration fee will also apply to transfers of
the SCDN, as applicable, because an additional year will be added to the term
of the SCDN, subject to the 10-year maximum, as part of the transfer process in
accordance with standard domain name lifecycle.
If the SCDN is not explicitly
renewed prior to the expiration date, it will be automatically renewed for a
single year in the same manner as non-single-character domain names. Prior to
the Expiration of the Subsequent Installment, the winning registrant must
complete the payment of the Subsequent Installment of the Winning Bid and the
registrar of record must complete the payment of the then-applicable
registration fee within fourteen (14) days of the auto-renewal, or the registry
reserves the right to explicitly delete the registration and make the SCDN
available through a subsequent auction or other allocation method. If the SCDN
is not renewed, then the winning registrant will be released from its
commitment to pay a future Subsequent Installment of the Winning Bid.
If a deletion by the registrar
of record occurs for the SCDN, the SCDN will enter the standard 30-day
Redemption Grace Period. If the SCDN is not restored during this period, the
SCDN will enter a 5-day Pending Delete Period and the SCDN will not be available
for re-registration and may be re-auctioned or placed through another
allocation method.
Fees
The First Installment of the
Winning Bid will be paid by the winning registrant to the Trust and will be
allocated by the Third Party Trustee as follows:
o
An amount agreed upon in advance
will be paid to (i) the third party auction service provider for auction
administration services and (ii) the Third Party Trustee for services relating
to the management and distribution of the funds in the Trust;
o
An amount, not more than
$1,000,000, will be held by the Trust as a reserve for expenses the Third Party
Trustee may incur to enforce (a) the Auction Agreement and (b) requirements the
selected nonprofit organization(s) must meet in order to receive the funds, such as using the funds toward areas of
public good of the Internet community; and
o The remaining amount of the First Installment of the
Winning Bid will be distributed to the selected nonprofit organization(s), as
discussed above.
Each Subsequent Installment of
the Winning Bid will be paid by the winning registrant to the Trust and will be
allocated by the Third Party Trustee as follows:
o An amount agreed upon in advance will be paid to the
Third Party Trustee for services relating to the management and distribution of
the funds in the Trust; and
o The remaining amount of the Subsequent Installment(s)
of the Winning Bid will be distributed to the nonprofit organization(s)
discussed above. The Third Party Trustee will notify Registry Operator upon
receipt of payment.
Exhibit
A to Schedule I of Appendix 7 - CONFIDENTIAL
To Schedule 1 to Appendix 7 (o.com
Service Description)
[REDACTED
FOR CONFIDENTIALITY]
.com Registry Agreement Appendix 8
.com Registry-Registrar Agreement
This Registry-Registrar Agreement (the "Agreement") is entered
into by and between VeriSign, Inc., a Delaware corporation, with a place of
business located at 12061 Bluemont Way, Reston, VA 20190, and its wholly owned
subsidiaries, including VeriSign
Sarl and VeriSign
Naming and Directory Services
LLC ("VNDS LLC") (collectively, "Verisign"), and , a
, with its principal place of business
located at ("Registrar"), through their authorized representatives,
and takes effect on the date executed by the final Party (the "Effective
Date"). Verisign and Registrar may be referred to individually as a
"Party" and collectively as the "Parties."
WHEREAS, multiple
registrars provide Internet
domain name registration services within the
.COM top-level domain wherein Verisign operates and maintains certain TLD
servers and zone files;
WHEREAS, Registrar wishes to register second-level domain names in the
multiple registrar system for the .COM TLD.
NOW, THEREFORE, for and in consideration of the mutual promises, benefits
and covenants contained herein and for other good and valuable consideration,
the receipt, adequacy and sufficiency of which are hereby acknowledged,
Verisign and Registrar, intending to be legally bound, hereby agree as follows:
1.
DEFINITIONS
1.1.
"Confidential Information" means all information and materials including, without limitation, computer software, data, information,
databases, protocols, reference implementation and documentation, and
functional and interface specifications, provided by the disclosing party to
the receiving party and marked or otherwise identified as Confidential, provided
that if a communication is oral, the Disclosing Party
will notify the Receiving Party in writing within 15
days of the disclosure.
1.2.
"DNS" refers
to the Internet domain name
system.
1.3.
"EPP" means the Extensible Provisioning Protocol.
1.4.
"ICANN" refers
to the Internet Corporation for Assigned Names
and Numbers.
1.5.
"IP" means Internet Protocol.
1.6.
The "Licensed Product" refers to the intellectual property required to access the Supported Protocol, and to the APIs,
and software, collectively.
1.7.
"Personal Data" refers to data about any identified or identifiable natural
person.
1.8.
"Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g.,
john.smith.name) levels, about
which Verisign or an affiliate engaged in providing
registry services maintains data in a registry database, arranges for such
maintenance, or derives revenue from such maintenance. A name in a registry database
may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive
name).
1.9.
“Registered Name Holder(s)” means the holder(s)
of a Registered Name.
1.10.
“Registrar
Accreditation Agreement” means that certain Registrar Accreditation Agreement
between Registrar and ICANN pursuant to which ICANN has accredited Registrar to
act as a registrar for one or more TLDs.
1.11.
"Registry TLD" means the .COM TLD.
1.12.
"Supported
Protocol" means Verisign's implementation of EPP, or any successor
protocols, supported by the System.
1.13.
The
"System" refers to the shared registration system operated by
Verisign for registration of Registered Names in the Registry TLD.
1.14. A "TLD"
is a top-level domain of the DNS.
2.
OBLIGATIONS OF THE PARTIES
2.1.
System Operation
and Access. Throughout the term of this Agreement, Verisign shall operate the System and
provide Registrar with access to the System to transmit domain name registration information for the Registry
TLD to the System. Nothing
in this Agreement entitles
Registrar to enforce any agreement between Verisign and ICANN.
2.2.
Maintenance of Registrations Sponsored
by Registrar. Subject to the provisions of this Agreement, ICANN
requirements, and Verisign requirements, including, without limitation, those
authorized by ICANN, Verisign shall maintain the registrations of Registered
Names sponsored by Registrar in the System during the term for which Registrar
has paid the fees required by Subsection 5.1.
2.3.
Distribution
of EPP, APIs and Software. No later than three (3) business days
after the Effective Date of this Agreement, Verisign shall make available to Registrar
(i) full documentation of the Supported
Protocol, (ii) "C" and/or
"Java" application program interfaces ("APIs") to the Supported
Protocol with documentation, and (iii) reference client software
("Software") that will allow Registrar to develop its system to
register second-level domain names through the System for the Registry TLD. If
Verisign elects to modify or upgrade the APIs and/or Supported Protocol,
Verisign shall provide updated APIs to the Supported Protocol
with documentation and updated Software to Registrar promptly as such
updates become available.
2.4.
Registrar Responsibility for Customer Support.
Registrar shall provide
(i) support to accept orders for registration,
cancellation, modification, renewal, deletion or transfer of Registered Names
and (ii) customer service (including
domain name record support) and billing and technical support to Registered
Name Holders. Registrar shall, consistent with ICANN
policy, provide to Registered Name Holders emergency contact or 24/7
support information for critical situations such as domain name hijacking.
2.5.
Data Submission
Requirements. As part of its registration and sponsorship of
Registered Names in the Registry TLD, Registrar shall submit complete data as
required or permitted: (a) by Verisign’s Registry Agreement with ICANN, as may be amended from time to time; and/or (b) by
technical specifications of the System that are made available to Registrar by
Verisign from time to time (collectively the “Required Data Elements”).
Registrar shall submit any corrections or updates from a Registered Name Holder relating to the registration information
for a Registered Name to Verisign in a timely manner.
2.6.
License. Registrar
grants Verisign a non-exclusive, royalty-free, nontransferable (except to ICANN or its designee
pursuant to Verisign’s Registry Agreement with ICANN)
worldwide limited license to the Required Data Elements: (a) for use as
required or permitted by technical specifications of the System as made
available to Registrar by Verisign from time to time; and/or (b) for use and
display as required or permitted by Verisign's Registry Agreement with ICANN,
as may be amended from time to time.
2.7.
Registrar's Registration Agreement
and Domain Name Dispute Policy.
(a)
Registrar shall have in effect a
valid and enforceable electronic or paper registration agreement with each
Registered Name Holder which may be amended from time to time by Registrar,
provided a copy is made available to Verisign. Registrar shall provide a copy
of Registrar's registration agreement upon request for same by Verisign.
Registrar shall include in its registration agreement those terms required by
this Agreement and other terms that are consistent with Registrar's obligations to Verisign under this
Agreement. Registrar shall employ in its domain name registration business the
Uniform Domain Name Dispute Resolution Policy and the Inter-Registrar Transfer
Policy, each as adopted by the ICANN Board on 26 August 1999 and 7 November
2008 and as each may be amended from time to time.
(b)
Registrar’s registration agreement with each Registered Name Holder shall
also include the following:
(i) a provision prohibiting the Registered Name Holder from
distributing malware, abusively operating
botnets, phishing, pharming, piracy, trademark or copyright
infringement, fraudulent or deceptive practices, counterfeiting or otherwise
engaging in activity contrary to
applicable law and providing (consistent with applicable law and any related
procedures) consequences for such activities, including
suspension of the registration of the Registered Name;
(ii) a provision that requires the Registered Name Holder
to acknowledge and agree that Verisign reserves the right to deny, cancel,
redirect or transfer any registration or transaction, or place any domain
name(s) on registry lock, hold or similar status,
as it deems necessary, in its unlimited and sole discretion: (1) to comply with specifications adopted
by any industry group generally
recognized as authoritative with respect to the Internet (e.g., RFCs),
(2) to correct mistakes made by
Verisign or any Registrar in connection with a domain name registration, (3) for the non-payment of fees to Verisign,
(4) to protect against imminent and substantial threats to the security and
stability of the Registry TLD, System, Verisign’s nameserver operations or the
internet, (5) to ensure compliance with applicable law, government rules
or regulations, or pursuant to any
legal order or subpoena of any government, administrative or governmental authority, or court of
competent jurisdiction, and/or (6) to stop or prevent any violations of any
terms and conditions of this Agreement, the Operational Requirements, or pursuant to Verisign’s Registry
Agreement with ICANN; and
(iii) a provision requiring the Registered Name Holder to indemnify, defend
and hold harmless Verisign and its subcontractors, and its and their
directors, officers, employees, agents, and affiliates from and against any and
all claims, damages, liabilities, costs and expenses, including reasonable
legal fees and expenses arising out of or relating to, for any reason whatsoever, the Registered Name
Holder's domain name registration. The registration agreement shall further
require that this indemnification obligation survive the termination or
expiration of the registration agreement.
2.8.
Secure Connection.
(a)
Registrar agrees
to develop and employ in its domain
name registration business all necessary technology and
restrictions to ensure that its connection to the System is secure. All data exchanged
between Registrar's system and the System
shall be protected to avoid
unintended disclosure of information. Registrar shall employ commercially reasonable measures to prevent its
access to the System granted hereunder from being used to (i) allow, enable,
or otherwise support
the transmission by e-mail,
telephone, or facsimile
of mass unsolicited, commercial
advertising or solicitations to entities other than its own existing customers;
or (ii) enable high volume, automated, electronic
processes that send queries or data to the systems of Verisign, any other
registry operated under an agreement
with ICANN, or any ICANN-accredited registrar, except as reasonably necessary
to register domain names or modify existing registrations in accordance with
any Operational Requirements.
(b)
Each EPP session shall be authenticated
and encrypted using two-way secure socket layer ("SSL") protocol. Registrar agrees
to authenticate every
EPP client connection with the
System using both an X.509 server certificate issued by a commercial
Certification Authority identified by the Registry and its Registrar password,
which it shall disclose only to its employees with a need to know. Registrar agrees
to notify Registry within four (4) hours of learning that its Registrar password
has been compromised in any way or if its server
certificate has been revoked by the issuing Certification Authority or
compromised in any way.
(c)
Upon prior written notification to
Registrar, Verisign may require other industry
standard security provisions, practices or technology to ensure that the
System is secure and stable,
which Verisign may adopt from time to time in its
sole and complete discretion.
2.8.1.
Handling of Personal
Data.
Verisign
shall notify Registrar of the purposes for which Personal Data submitted to
Verisign by Registrar is collected, the intended recipients (or categories of
recipients) of such Personal Data, and the mechanism for access to and correction of such Personal
Data. Verisign shall take reasonable steps to protect Personal Data from
loss, misuse, unauthorized disclosure, alteration or destruction. Verisign
shall not use or authorize the use of Personal Data in a way that is
incompatible with the notice provided to registrars. Verisign may from time to time use the demographic data collected for statistical analysis, provided that this analysis will
not disclose individual Personal Data and provided that such use is compatible
with the notice provided to registrars regarding the purpose and procedures for
such use.
2.8.2. Authorization Codes. Registrar shall not provide
identical Registrar- generated authorization <authinfo> codes for domain
names registered by different Registered Name Holders with the same Registrar.
Verisign in its sole discretion may choose to modify <authinfo> codes for
a given domain and shall notify the sponsoring registrar of such modifications
via EPP compliant mechanisms (i.e., EPP<poll> or EPP<domain:Info>).
Documentation of these mechanisms shall be made available to Registrar by Verisign. The Registrar shall provide the Registered Name Holder with timely
access to the authorization code along with the ability to modify the
authorization code. Registrar shall respond to any inquiry by a Registered Name
Holder regarding access to and/or modification of an authorization code within
five (5) calendar days.
2.9.
Domain Name Lookup
Capability. Registrar agrees to employ in its domain name registration business Verisign's registry
domain name lookup capability to determine
if a
requested domain name is available
or currently unavailable for registration. Registrar also agrees, at its expense, to provide a Registration Data Directory Service
providing free public query-based access to up-to-date (i.e., updated
at least daily) data concerning all active Registered Names sponsored by Registrar for the Registry
TLD. The data accessible
shall consist of elements that are designated from time to time according to an
ICANN adopted specification or policy or the Registrar Accreditation Agreement
between Registrar and ICANN.
2.10.
Transfer
of Sponsorship of Registrations. Registrar agrees to implement
transfers of Registered Name registrations from another registrar to Registrar
and vice versa or from one Registered Name Holder to another pursuant to the
Inter-Registrar Transfer Policy as may be amended from time to time by ICANN (the "Transfer Policy").
2.11.
Time. Registrar agrees that in the event of any dispute concerning
the time of the entry of a domain name registration into the registry database,
the time shown in the Verisign records shall control.
2.12.
Compliance with Operational
Requirements. Registrar shall comply with each of the following
requirements, and further shall include in its registration agreement with each
Registered Name Holder, as applicable, an obligation for such Registered Name
Holder to comply with each of the following requirements:
(a)
ICANN standards,
policies, procedures, and practices for which Verisign has monitoring
responsibility in accordance with the Registry Agreement or other arrangement
with ICANN; and
(b)
Operational
standards, policies, procedures, and practices for the Registry TLD established
from time to time by Verisign in a non-arbitrary manner and applicable to all registrars ("Operational Requirements"), including affiliates of
Verisign, and consistent with Verisign's Registry Agreement with ICANN, as
applicable, upon Verisign's notification to Registrar of the establishment of those terms and
conditions.
2.13.
Resolution of Technical Problems
or Breach of Agreement. Registrar agrees to
employ necessary employees, contractors, or agents with sufficient technical
training and experience to respond
to and fix all technical problems concerning the use of the Supported Protocol, the APIs and the
systems of Verisign in conjunction with Registrar's systems. Registrar agrees
that in the event of significant degradation of the System or other emergency,
or upon Registrar's violation of Operational Requirements or breach of this
Agreement, Verisign may, in its sole discretion, temporarily suspend or
restrict access to the System. Such temporary suspensions or restrictions shall
be applied in a
non-arbitrary manner and shall apply fairly to any registrar similarly
situated.
2.14.
Prohibited Domain Name Registrations. In addition
to complying with ICANN
standards, policies, procedures, and practices limiting domain names that may
be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain
names that may be registered. Registrar
further acknowledges and agrees that Verisign reserves the right to deny,
cancel, redirect or transfer any registration or transaction, or place any domain name(s)
on registry lock,
hold or similar
status, as it deems
necessary, in its unlimited and sole discretion, for the purposes set forth in Section 2.7(b)(ii) of this Agreement.
2.15.
ICANN Requirements. Verisign's
obligations hereunder are subject to modification at any time as the result of
ICANN-mandated requirements, including consensus policies. Notwithstanding anything
in this Agreement to the contrary, Registrar shall comply with any such ICANN
requirements in accordance with the timeline
defined by ICANN.
2.16. Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full force and effect the
Registrar Accreditation Agreement and its accreditation by ICANN as a registrar
for the Registry TLD.
3.
LICENSE
3.1.
License Grant. Subject
to the terms and conditions of this Agreement, Verisign hereby grants Registrar
and Registrar accepts a non-exclusive, royalty-free, nontransferable, worldwide
limited license to use for the term and purposes of this Agreement the Licensed
Product, as well as updates and redesigns thereof, to provide domain name registration services
in the Registry TLD only and for no other purpose. The Licensed Product, as well as updates
and redesigns thereof,
will enable Registrar
to register domain names in
the Registry TLD with the Registry on
behalf of its Registered Name Holders. Registrar, using the Licensed Product,
as well as updates and redesigns thereof, will
be able to invoke the following operations on the System:
(i) check the availability of a domain name, (ii) register
a domain name, (iii) re-register a domain name, (iv) cancel
the registration of a domain name it has registered, (v) update the nameservers of a domain name, (vi) transfer a domain name from another
registrar to itself
with proper authorization, (vii) query a domain name registration record, (viii) register a nameserver, (ix) update the IP addresses of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and
(xii) establish and end an authenticated session.
3.2.
Limitations on Use. Notwithstanding
any other provisions in this Agreement, except
with the written
consent of Verisign, Registrar shall not: (i) sublicense the Licensed Product
or otherwise permit any use of the Licensed Product by or for the benefit of
any party other than Registrar, (ii) publish, distribute or permit disclosure
of the Licensed Product other than to employees, contractors, and agents of Registrar
for use in Registrar's domain
name registration business, (iii) decompile, reverse engineer, copy or
re-engineer the Licensed Product
for any unauthorized purpose, (iv) use or permit use of the Licensed
Product in violation of any federal, state or local rule, regulation or law, or for any unlawful
purpose. Registrar agrees to employ the necessary measures to prevent its
access to the System granted hereunder from being used to (i) allow, enable, or
otherwise support the transmission by e-mail, telephone, or facsimile of mass
unsolicited, commercial advertising or solicitations to entities other than
Registrar's customers; or (ii) enable high volume, automated, electronic
processes that send queries or data to the systems of Verisign, any other
registry operated under an agreement with ICANN, or any ICANN- Accredited
Registrar, except as reasonably necessary to register domain names or modify
existing registrations in accordance with any Operational Requirements.
3.3.
Changes to Licensed Materials. Verisign may from time to time replace or make
modifications to the Licensed Product
licensed hereunder. Verisign
will provide Registrar with at least ninety (90) days’
notice prior to the implementation of any material changes to the Supported
Protocol, APIs or software licensed hereunder.
4.
SUPPORT SERVICES
4.1.
Engineering
Support. Verisign agrees to provide Registrar
with reasonable engineering telephone support
(between the hours of 9 a.m. to 5 p.m. EST or at such other
times as may be mutually
agreed upon) to address engineering issues arising in connection
with Registrar's use of the System.
4.2.
Customer Service Support. During
the term of this Agreement, Verisign will provide reasonable telephone, web based and e-mail customer
service support to Registrar,
not Registered Name Holder or prospective customers
of Registrar, for nontechnical issues solely relating to the System and its
operation. Verisign will provide Registrar with a telephone number and e-mail
address for such support during implementation of the Supported Protocol,
APIs and Software.
First-level telephone support
will be available on a
7-day/24-hour basis.
5.
FEES
5.1.
Registration Fees.
(a)
Registrar agrees to pay Verisign
the non-refundable fees set forth in Exhibit A, or such other amount as may be
established in accordance with the notice provision set forth in Section 5.1(b)
below, for initial and renewal registrations and other incidental and ancillary
services provided by Verisign (collectively, the "Registration
Fees").
(b)
Verisign reserves the right to
adjust the Registration Fees, provided that any price increase shall be made
only upon six (6) months prior notice to Registrar (by e-mail, hand, by
registered mail, or by courier or express delivery service), and provided that
such adjustments are consistent with Verisign's Registry Agreement with ICANN.
(c)
Registrars shall
provide Verisign a payment security
comprised of an irrevocable
letter of credit or cash deposit (the "Payment Security"). The amount
of the Payment Security establishes Registrar's credit limit
in the Verisign System and should be based on anticipated
monthly level of registrations and other billable transactions. Registrar agrees to modify its Payment Security to support increases
in billable transaction volumes as required by the Verisign credit and billing
policies. Verisign will invoice Registrar monthly in arrears for each month's
Registration Fees. All Registration Fees are due immediately upon receipt of
Verisign's monthly invoices. In order to satisfy any outstanding account
balances, Verisign may draw upon the Registrar's Payment Security. If this occurs,
Registrar agrees to replenish Payment
Security to the pre-draw level immediately upon completion of draw. If Registrar's Payment
Security is depleted,
registration of domain names for the Registrar will be suspended and new registrations will not be accepted until the Payment
Security is replenished.
(d)
The Registration Fees due under this Agreement are exclusive of tax. All taxes,
duties, fees and other governmental charges of any kind (including business,
levy, sales, turnover, services, use and value-added taxes, but excluding taxes
based on the net income of Verisign) which are imposed by or under the
authority of any government or any political subdivision thereof on the fees
for any services, software
and/or hardware shall be borne by Registrar
and shall not be considered a part of, a deduction
from or an offset against such Registration Fees. All payments due to Verisign
shall be made without any deduction or withholding on account of any tax, duty, charge
or penalty except
as required by law,
in which case, the sum payable by Registrar from which such deduction or withholding is to be made shall be
increased to the extent necessary to ensure that, after making such deduction
or withholding, Verisign receives and retains (free from any liability with respect thereof)
a net sum equal to the sum it would have received but for such
deduction or withholding being required.
5.2.
Change in
Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name Holder's existing
domain name registration from another
registrar by following the Transfer Policy.
(a)
For each transfer
of the sponsorship of a domain-name registration under the Transfer Policy,
Registrar agrees to pay Verisign the renewal registration fee associated with a
one-year extension, as set forth above. The losing registrar's Registration
Fees will not be refunded as a result of any such transfer.
(b)
For a transfer approved
by ICANN under
Part B of the Transfer
Policy, Registrar agrees to pay Verisign US $0 (for transfers
of 50,000 names or fewer) or US
$50,000 (for transfers of more than 50,000 names).
Fees under
this Section 5.2 shall be due immediately upon receipt of Verisign's invoice pursuant to the Payment Security.
5.3.
Charges for ICANN Fees. Registrar
agrees to pay to Verisign, within five (5) days of the date when due, any
variable registry-level fees paid by Verisign to ICANN, which fees shall be
secured by the Payment Security. The fee will consist of two components; each
component will be calculated by ICANN for each registrar:
(a)
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 fiscal
year but shall
not exceed the amount set forth
in the Registry Agreement.
(b)
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 fiscal year, but the sum of the per registrar
fees calculated for all registrars shall not exceed
the total Per-Registrar Variable funding established pursuant to the approved ICANN
Budget.
5.4.
Non-Payment of Fees. Timely
payment of fees owing under this Section 5 is a material condition of
performance under this Agreement. In the event that Registrar fails to pay its
fees within five (5) days of the date when due, Verisign may: (i) stop accepting new initial or renewal
registrations from Registrar; (ii) delete the domain names associated
with invoices not paid in full from the Registry database; (iii) give written notice of termination of this Agreement pursuant to Section
6.1(b) below; and (iv) pursue
any other remedy under this
Agreement.
6.
MISCELLANEOUS
6.1.
Term of Agreement and Termination.
(a)
Term of the Agreement;
Revisions. The duties and obligations of the Parties under this Agreement shall apply from the Effective
Date through and including
the last day of the calendar month sixty (60) months from the Effective
Date (the "Initial
Term"). Upon conclusion of the Initial Term, all provisions of this
Agreement will automatically renew for successive five (5) year renewal periods until the Agreement has been terminated as provided herein,
Registrar elects not to
renew, or Verisign
ceases to operate
the registry for the Registry
TLD. In the event that revisions
to Verisign's Registry-Registrar Agreement are approved
or adopted by ICANN,
Registrar shall have thirty (30) days from the date of notice of any such revision to review,
comment on, and execute an amendment substituting the revised agreement in place of this Agreement, or Registrar may, at its option exercised within such
thirty (30) day period, terminate this Agreement immediately by giving written
notice to Verisign; provided, however, that in the event Verisign does not
receive such executed amendment or notice of termination from Registrar within
such thirty (30) day period
of the date of the notice,
Registrar shall be deemed to have executed
such amendment as of the
thirty-first (31st) day after the date of the notice.
(b)
Termination For Cause. In the event that either Party materially breaches
any term of this Agreement including any of its representations and
warranties hereunder and such breach is not substantially cured within thirty
(30) calendar days after written notice thereof is given by the other Party,
then the non- breaching Party may, by giving written notice thereof to the
other Party, terminate this Agreement as of the date specified in such notice
of termination.
(c)
Termination at Option of Registrar. Registrar may terminate this Agreement at
any time by giving Verisign thirty (30) days’ notice of termination.
(d)
Termination
Upon Loss of Registrar's Accreditation. This Agreement shall terminate
immediately in the event Registrar's accreditation for the Registry TLD by
ICANN, or its successor, is terminated or expires without renewal.
(e)
Termination in the Event that Successor
Registry Operator is Named. This
Agreement shall terminate in the event that the U.S. Department of Commerce or
ICANN, as appropriate, designates another entity to operate the registry for
the Registry TLD.
(f)
Termination in the Event of
Bankruptcy. Either Party may terminate this Agreement if the other
Party is adjudged
insolvent or bankrupt, or if proceedings are instituted by or against a Party seeking
relief, reorganization or arrangement
under any laws relating to insolvency, or seeking any assignment for the benefit of creditors, or seeking the
appointment of a receiver, liquidator or trustee of a Party's property
or assets or the liquidation, dissolution or winding
up of a Party's business.
(g)
Effect of Termination. Upon
expiration or termination of this Agreement, Verisign will, to the extent it has the authority to do so, complete the registration
of all domain names processed by Registrar prior to the date of such expiration
or termination, provided that Registrar's payments to Verisign for Registration
Fees are current and timely. Immediately upon any expiration or termination of
this Agreement, Registrar shall (i) transfer its sponsorship of Registered Name
registrations to another
licensed registrar(s) of the Registry, in compliance with Part B of the Transfer Policy, or
any other procedures established or approved by the U.S. Department of Commerce or ICANN, as appropriate, and (ii) either return to Verisign or certify to
Verisign the destruction of all Confidential Information it has received under
this Agreement. In the event of
termination, Verisign reserves the right to immediately contact
any and all Registered Name Holders to facilitate the orderly and stable transition of Registered Name Holders
to other ICANN-accredited registrars. All fees owing to Verisign
shall become immediately due
and payable.
(h)
Survival. In
the event of termination of this Agreement, the following shall survive: (i)
Sections 2.6 (License), 2.7 (Registrar's Registration Agreement and Domain Name Dispute Policy),
2.8.1 (Handling of Personal Data),
6.1(g) (Effect of
Termination), 6.1(h) (Survival), 6.2 (No Third Party Beneficiaries;
Relationship of the Parties), 6.5 (Amendment in Writing), 6.6 (Attorneys' Fees),
6.7 (Dispute
Resolution; Choice of Law; Venue), 6.8 (Notices), 6.10 (Use of Confidential
Information), 6.11 (Delays or Omissions; Waivers), 6.12 (Limitation of
Liability), 6.13 (Construction), 6.14 (Intellectual Property), 6.15(c)
(Disclaimer of Warranties), 6.16 (Indemnification), and 6.17 (Entire Agreement;
Severability); (ii) the Registered
Name Holder's obligations to indemnify, defend, and hold harmless Verisign, as
stated in Section 2.7(b)(iii); and (iii) Registrar's payment obligations as set forth
in Section 5 with respect
to fees incurred during the term of this Agreement.
6.2.
No Third
Party Beneficiaries; Relationship of the Parties.
This Agreement does not provide and shall not be construed to provide third
parties (i.e., non-parties to this Agreement),
including any Registered Name Holder, with any remedy,
claim, cause of action or privilege. Nothing
in this Agreement shall be construed as creating an employer-
employee or agency relationship, a partnership or a joint venture between the
Parties.
6.3.
Force Majeure. Neither
Party shall be responsible for any failure to perform any obligation (other
than payment obligations) or provide service hereunder because of any Act of God, strike,
work stoppage, cyberattack, to protect against
imminent and substantial threats to the security and
stability of the Registry TLD, System, Verisign’s name server operations or the
internet, governmental acts or directives, war, riot or civil commotion,
equipment or facilities shortages which are being experienced by providers of
telecommunications services generally, or other similar force beyond such
Party's reasonable control.
6.4.
Further Assurances. Each Party hereto shall execute and/or cause to be delivered to each other Party
hereto such instruments and other documents, and shall take such other actions, as such other Party may
reasonably request for the purpose of carrying out or evidencing any of the
transactions contemplated by this Agreement.
6.5.
Amendment in Writing. Except
as otherwise provided in this Agreement, any amendment or supplement to this Agreement shall be in writing and duly executed
by both Parties. Any new services
approved by ICANN
and purchased by Registrar will be subject to such terms and conditions as may be established by Verisign through
an appendix to this
Agreement or such other agreement executed by Registrar and Verisign.
6.6.
Attorneys' Fees. If
any legal action or other legal proceeding (including arbitration) relating to
the performance under this Agreement or the enforcement of any provision of
this Agreement is brought against either Party hereto, the prevailing Party
shall be entitled to recover
reasonable attorneys' fees,
costs and disbursements (in addition to any
other relief to which the prevailing Party may be entitled).
6.7.
Dispute Resolution; Choice of Law; Venue. The Parties
shall attempt to resolve
any disputes between them prior to
resorting to litigation. This Agreement is to be construed in accordance with
and governed by the internal laws of the Commonwealth of Virginia, United
States of America without giving effect to any choice of law rule that would
cause the application of the laws of any jurisdiction other than the internal
laws of the Commonwealth of Virginia to the rights and duties of the Parties.
Any legal action or other legal proceeding relating to this Agreement or the
enforcement of any provision of this Agreement shall be brought or otherwise
commenced in any state or federal court located in the eastern district of the
Commonwealth of Virginia. Each Party to this Agreement expressly and
irrevocably consents and submits to the jurisdiction and venue of each state
and federal court located in the eastern district of the Commonwealth of
Virginia (and each appellate court located in the Commonwealth of Virginia) in connection
with any such legal proceeding.
6.8.
Notices. Any notice or other communication required or permitted to be delivered to any Party under this
Agreement shall be in writing and shall be deemed properly delivered, given and
received when delivered (by hand, by registered mail, by courier or express
delivery service, by e-mail or by telecopier during business hours) to the
address or telecopier number
set forth beneath
the name of such Party
below, unless Party
has given a notice of a
change of address in writing:
if to Registrar:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:
with a copy to:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:
if to Verisign:
VeriSign, Inc.
12061 Bluemont Way
Reston, VA
20190 Attn: General Counsel
Telephone: +1 703 948 3200
Facsimile: +1
703 435 4921 E-Mail: legal@verisign.com
With a copy to (which shall not constitute notice):
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Attn: Customer
Affairs Office Telephone: +1
703 948 3200
Facsimile: +1 703 948 3977
E-Mail: cao@verisign-grs.com
6.9.
Assignment/Sublicense. Except
as otherwise expressly provided herein, the provisions of this Agreement shall
inure to the benefit of and be binding upon, the successors and permitted assigns
of the Parties hereto. Registrar shall not assign,
sublicense or transfer its rights or obligations under this
Agreement to any third person without the prior written consent of Verisign.
Verisign may assign its rights or obligations under this Agreement to an
affiliate without the consent of Registrar.
6.9.1. Assignment in Connection with Assignment of Agreement with ICANN. In the event that Verisign's Registry
Agreement with ICANN for the Registry TLD is validly assigned, Verisign's
rights under this Agreement shall be automatically assigned to the assignee of
the Registry Agreement, provided that the assignee assumes the duties of
Verisign under this Agreement. In the event that Registrar's Registrar
Accreditation Agreement with ICANN for the Registry TLD is validly
assigned, Registrar's rights under
this Agreement shall be automatically assigned to the assignee of Registrar’s Registrar
Accreditation Agreement, provided that the subsequent registrar assumes the
duties of Registrar under this Agreement.
6.10.
Use of Confidential
Information. During the term of this
Agreement, each Party (the "Disclosing Party") may disclose its
Confidential Information to the other Party (the "Receiving Party"). Each Party's use and disclosure of Confidential Information disclosed hereunder are subject to the following terms and
conditions:
(a)
The Receiving Party shall treat as
strictly confidential, and use all reasonable efforts to preserve the secrecy
and confidentiality of, all Confidential Information of the Disclosing Party,
including implementing reasonable physical security measures and operating
procedures.
(b)
The Receiving
Party agrees that it will use any Confidential Information of the Disclosing
Party solely for the purpose of exercising its right or performing its
obligations under this Agreement and for no other purposes whatsoever.
(c)
The Receiving Party shall make no
disclosures whatsoever of any Confidential Information of the Disclosing Party
to others; provided, however, that if the Receiving Party is a corporation,
partnership, or similar entity, disclosure is permitted to the Receiving
Party's officers, employees, contractors and agents who have a demonstrable need to know such Confidential Information, provided
the Receiving Party shall advise
such personnel of the confidential nature of the Confidential Information and take
reasonable steps to maintain the confidentiality thereof.
(d)
The Receiving
Party shall not modify or remove any confidentiality legends and/or copyright
notices appearing on any Confidential Information of the Disclosing Party.
(e)
The Receiving
Party agrees not to prepare any derivative works based on the Confidential
Information.
(f)
Notwithstanding the foregoing, this Subsection 6.10 imposes no obligation upon the parties with respect to
information that (i) is disclosed in the absence of a confidentiality agreement and such disclosure was agreed to by the
Disclosing Party in writing
prior to such disclosure; or (ii) is or has entered the public
domain through no fault of the Receiving Party; or (iii) is known by the
Receiving Party prior to the time of disclosure; or (iv) is independently
developed by the Receiving Party without use of the Confidential Information;
or (v) is made generally
available by the Disclosing Party without restriction on disclosure, or (vi) is required to be disclosed by law,
regulation or court order; provided, that in the event
the Receiving Party
is required by law, regulation or court order to disclose any of Disclosing Party's
Confidential Information, Receiving Party will promptly notify
Disclosing Party in writing prior
to making any such disclosure
in order to facilitate Disclosing Party seeking a protective order or other
appropriate remedy from the proper authority, at the Disclosing Party's
expense. Receiving Party agrees to cooperate with Disclosing Party in seeking
such order or other remedy. Receiving Party further agrees that if Disclosing
Party is not successful in precluding the requesting legal body from requiring the disclosure of the Confidential Information, it will furnish only that
portion of the Confidential Information that is legally required.
6.11.
Delays or Omissions;
Waivers. No failure on the part of either Party to exercise any
power, right, privilege or remedy under this Agreement, and no delay on the
part of either Party in exercising any power, right,
privilege or remedy
under this Agreement, shall operate as a waiver of such power, right, privilege or
remedy; and no single or partial exercise or waiver of any such power, right,
privilege or remedy shall preclude any other or further exercise thereof
or of any other power, right, privilege
or remedy. No Party shall be deemed to have waived any claim
arising out of this Agreement, or any power, right, privilege or remedy under
this Agreement, unless the waiver of such claim, power, right, privilege or
remedy is expressly set forth in a written instrument duly executed and
delivered on behalf of such Party; and any such waiver shall not be applicable or have any effect except in the specific instance
in which it is given.
6.12.
Limitation of Liability.
(a)
IN NO EVENT WILL VERISIGN BE
LIABLE TO REGISTRAR FOR ANY SPECIAL, INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY
OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
RESULTING FROM LOSS OF
PROFITS, ARISING OUT OF OR IN CONNECTION WITH THIS AGREEMENT, EVEN IF VERISIGN
HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.IN NO EVENT SHALL THE
MAXIMUM AGGREGATE LIABILITY OF THE PARTIES EXCEED THE LESSER OF (I) THE TOTAL
AMOUNT PAID TO VERISIGN UNDER THE TERMS OF THIS AGREEMENT FOR THE IMMEDIATELY PRECEDING TWELVE (12) MONTH
PERIOD, OR (ii) $500,000 USD.
(b)
THE LIABILITY CAP
AND EXCLUSION OF DAMAGES SET FORTH IN SECTION 6.12(a) SHALL NOT APPLY TO
SECTION 6.10 (CONFIDENTIALITY) AND SECTION 6.16 (INDEMNIFICATION).
6.13.
Construction. The Parties agree that any rule of construction to the effect
that ambiguities are to be resolved against the drafting Party shall not be
applied in the construction or interpretation of this Agreement.
6.14.
Intellectual Property. Subject
to Section 2.6 above, each Party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service
marks, copyrights, trade secrets, proprietary processes and all other forms of
intellectual property.
6.15.
Representations and Warranties
(a)
Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly
existing and in good standing
under the law of
, (2) it has all requisite corporate power and authority to execute,
deliver and perform its obligations under this Agreement, (3) it is, and during
the term of this Agreement will continue to be, accredited by ICANN or its
successor, pursuant to the Registrar Accreditation Agreement or a successor
agreement approved by ICANN, (4) the execution, performance and delivery
of this Agreement has been duly authorized by Registrar, and (5) no
further approval, authorization or consent of any governmental or regulatory
authority is required to be obtained or made by Registrar in order for it to
enter into and perform its obligations under this Agreement.
(b)
Verisign. Verisign represents and warrants that: (1) it is a corporation duly incorporated,
validly existing and in good standing under the laws of the State of Delaware,
(2) it has all requisite corporate
power and authority to execute, deliver and perform its obligations under this
Agreement, (3) the execution,
performance and delivery of this Agreement has been duly authorized by
Verisign, and (4) no further
approval, authorization or consent of any governmental or regulatory authority
is required to be obtained or made by Verisign in order for it to enter into
and perform its obligations under this Agreement.
(c)
Disclaimer of Warranties. The
LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs AND SOFTWARE ARE PROVIDED
"AS-IS" AND WITHOUT ANY WARRANTY OF ANY KIND. VERISIGN EXPRESSLY
DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF MERCHANTABILITY OR
SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
OF THIRD PARTY RIGHTS. VERISIGN DOES NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP,
APIs OR SOFTWARE WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF
THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE
WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT
DEFECTS IN THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE WILL
BE CORRECTED. FURTHERMORE, VERISIGN
DOES NOT WARRANT
NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE LICENSED
PRODUCT, SUPPORTED PROTOCOL, EPP, APIs, SOFTWARE OR
RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY, RELIABILITY, OR
OTHERWISE. SHOULD THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR
SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY
SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.
6.16.
Indemnification. Registrar,
at its own expense and within thirty (30) days of presentation of a demand by
Verisign under this paragraph, will indemnify, defend and hold harmless
Verisign and its employees, directors, officers, representatives, agents and
affiliates, against any claim, suit, action, or other proceeding brought
against Verisign or any affiliate of Verisign based
on or arising from any claim or alleged claim
(i) relating to any product or service of Registrar;
(ii) relating to any agreement, including Registrar's dispute policy,
with any Registered Name Holder of Registrar; or (iii) relating
to Registrar's domain name
registration business, including, but not limited to, Registrar's advertising,
domain name application process, systems and other processes, fees charged,
billing practices and customer service; provided, however, that in any such
case: (a) Verisign provides Registrar with prompt notice of any such claim, and
(b) upon Registrar's written request, Verisign will provide to Registrar all
available information and assistance reasonably necessary for Registrar to
defend such claim, provided that Registrar reimburses Verisign for its actual
and reasonable costs. Verisign shall have the right to control the defense of Verisign to any claim
or in litigation, through counsel
of its choice, whose fees shall be subject to indemnification as
provided herein. Registrar will not enter into any settlement or compromise of
any such indemnifiable claim without Verisign's prior written consent, which consent shall not be unreasonably withheld.
Registrar will pay any and all costs, damages, and
expenses, including, but not limited to, reasonable attorneys' fees and costs
awarded against or otherwise incurred by Verisign in connection with or arising
from any such indemnifiable claim, suit, action or proceeding.
6.17.
Entire Agreement; Severability. This Agreement, which includes Exhibits
A and B, constitutes the entire agreement between the Parties concerning the subject matter hereof
and supersedes any prior agreements, representations, statements,
negotiations, understandings, proposals or undertakings, oral or written, with
respect to the subject matter expressly set forth herein. If any provision of
this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced
to the maximum extent permissible so as to effect the intent of the
Parties, and the validity, legality and enforceability of the remaining provisions
of this Agreement shall not in any way be affected or impaired thereby. If
necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement
to replace the unenforceable
language with enforceable language that reflects such intent as closely as
possible.
6.18. Service Level Agreement. Appendix 10, as may be amended from time to time, of the
Registry Agreement shall be incorporated into this Agreement and attached
hereto as Exhibit B.
IN
WITNESS WHEREOF, the Parties hereto
have executed this Agreement as of the Effective Date.
Verisign
By:
Name:
Title:
Date:
Registrar
Company Name:
By:
Name:
Title:
Date: _________________________________
Exhibit A to Appendix 8 REGISTRATION FEES
1.
Domain-Name Initial
Registration Fee
Registrar agrees
to pay US $10.26 per annual increment of an initial
domain name registration, or such other amount as may be established in accordance with
the notice provision set forth in Section 5.1(b) above.
2. Domain-Name Renewal
Fee
Registrar agrees
to pay US $10.26 per annual increment of a domain
name registration renewal,
or such other amount as may be established in accordance with the notice
provision set forth in Section 5.1(b) above.
3. Domain Name Transfer
Registrar agrees
to pay US $10.26 per domain name that is transferred to Registrar from another
ICANN-Accredited Registrar, or such other
amount as may be established in accordance with the
notice provision set forth in Section 5.1(b) above.
4. EPP Update
to Restore a Name
Registrar agrees
to pay US $40.00 per use of the EPP Update command to restore a domain name, or such other
amount as may be established in accordance with the notice provision set forth in Section 5.1(b) above.
5. Sync
Registrar agrees
to pay US $2.00, plus $1.00 per month of the sync, for each use of the
Supported Protocol Sync command, or such other
amount as may be established in accordance with
the notice provision set forth in Section 5.1(b) above.
Exhibit B to
Appendix 8
SERVICE LEVEL AGREEMENT
See Appendix 10 to the .com Registry Agreement, as may be amended from time to time.
.com Registry Agreement Appendix 9
Approved Services
The
Agreement specifies a "Process for Consideration of Proposed Registry
Services." The following Registry Services are specifically identified as
having been approved by ICANN prior to the Effective Date. As such,
notwithstanding any other provisions of the Agreement, Verisign shall be free
to deploy the following Registry Services:
- Consolidate/Sync Service, in accordance with Registry
Operator’s Registrar Reference Manual;
- Internationalized Domain Names, in accordance with the Letter
from Rusty Lewis to Paul Twomey dated
13 October 2003;
- Restore, which allows use of the RRP Restore or EPP Update
command to retrieve a previously deleted domain name registration during
the Redemption Grace Period (approved by ICANN in accordance with Registry
Operator’s Registrar Reference Manual;
- Wait Listing Service, in accordance with the letter
from John O. Jeffrey to Russell Lewis dated
26 January 2004;
- Transfer Dispute Resolution, in accordance with the Registrar
Transfer Dispute Resolution Policy, dated 12 July 2004 (as may be amended
or superseded by ICANN), and Registry Operator's Supplemental Rules for
Registrar Transfer Disputes;
·
DNS Update Service, in accordance
with https://www.icann.org/en/system/files/files/icann-to-verisign-04apr07-en.pdf
dated April 11, 2007;
·
DNSSEC, in accordance with
https://www.icann.org/en/system/files/files/icann-to-verisign-2009011-06nov09-en.pdf
dated November 7, 2009;
·
Bulk Transfer after Partial
Portfolio Acquisition (“BTAPPA”) Restore, in accordance with https://www.icann.org/resources/board-material/minutes-2009-12-09-en
dated December 9, 2009;
·
Domain Name WhoWas, in accordance
with https://www.icann.org/en/system/files/files/verisign-whowas-16jul09-en.pdf,
dated July 16, 2009;
·
IDN DNS Updates, in accordance
with https://www.icann.org/en/system/files/files/icann-to-verisign-200906-10jul09-en.pdf,
dated July 10, 2009;
·
Registry Lock Service, in
accordance with https://www.icann.org/en/system/files/files/icann-to-verisign-200905-10jul09-en.pdf,
dated July 10, 2009;
·
Registry-Registrar Two-Factor
Authentication Services, in accordance with https://www.icann.org/en/system/files/files/icann-to-verisign-200904-10jul09-en.pdf,
dated July 10, 2009;
·
Verification Code Extension for
Extensible Provisioning Protocol, in accordance with https://www.icann.org/en/system/files/correspondence/papac-to-kane-27feb17-en.pdf, dated February 27, 2017;
·
Registration of o.com Domain Name
with a Single-Character Label in accordance with the Second Amendment
to the .COM Registry Agreement, dated March 27, 2019, available at
https://itp.cdn.icann.org/en/files/registry-agreements/com/com-amend-2-pdf-27mar19-en.pdf;
·
Modification to Verification Code
Extension for Extensible Provisioning Protocol, in accordance with
https://www.icann.org/en/system/files/files/weinstein-to-kane-14feb22-en.pdf,
dated February 14, 2022;
·
Two-Factor Authentication Service,
in accordance with
https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-27jul22-en.pdf,
dated July 27, 2022;
·
Domain Name Registration
Validation Per Applicable Law, in accordance with
https://www.icann.org/en/system/files/correspondence/weinstein-to-orentas-08sep22-en.pdf,
dated September 8, 2022; and
·
Extensible Provisioning Protocol
Service and Registration Validation per Applicable Law Service, in accordance
with https://www.icann.org/en/system/files/correspondence/weinstein-to-kane-25oct23-en.pdf,
dated October 25, 2023.
.com Registry Agreement Appendix 10
Service Level Agreement (SLA)
VeriSign,
Inc. ("Registry Operator") strives to provide a world-class
level of service to its customers. This Service Level Agreement ("SLA")
provides remedies in the form of SLA Credits (as defined in section 2 below)
should the operational performance of Registry Operator fall below certain
Performance Specifications identified in Appendix 7.
1.
Definitions.
Capitalized
terms used herein and not otherwise defined shall have the definitions ascribed
to them in the Registry Agreement, including, but not limited to Appendix 7.
2. SLA
Credits.
If the
Registry Operator fails to meet the Performance Specifications defined in
Appendix 7, Section 6 thereof, to which Credit Levels apply, the Registry
Operator shall pay credits to ICANN-Accredited Registrar(s) in accordance with
the identified Credit Level for such failed Performance Specifications metrics,
calculated in accordance with the Credit Level tables set forth in this Section
2 ("SLA Credit"). The SLA Credit due to each ICANN-Accredited
Registrar shall be paid as an offset to registrations and other fees owed to
Registry Operator by the ICANN-Accredited Registrar. SLA Credits represent the
total credits, penalties and/or liabilities that may be assessed to the
Registry Operator for a breach of the Performance Specifications set forth in
Appendix 7. All SLA Credits shall be paid in U.S. Dollars. The Credit Level
Table (Refer to Table SLA Credits) indicates the corresponding Credit Level for
each Performance Specification to which Credit Levels apply. This SLA will be
reconciled on a quarterly basis and unless otherwise specified in this SLA, SLA
Credits will be issued on a quarterly basis.
|
App. 7 Reference
|
Performance
Specification
|
SRS
|
Name
Server
|
Whois
|
|
6.2.2,
6.2.3,
6.2.4
|
Service
Availability
|
Level
2
|
Level
1
|
Level
2
|
|
6.3.1
|
Planned
Outage - Duration
|
Level
6
|
NA
|
NA
|
|
6.3.2
|
Planned
Outage - Timeframe
|
Level
5
|
NA
|
NA
|
|
6.3.3
|
Planned
Outage - Notification
|
Level
5
|
NA
|
NA
|
|
6.4.1
|
Extended
Planned Outage - Duration
|
Level
6
|
NA
|
NA
|
|
6.4.2
|
Extended
Planned Outage - Timeframe
|
Level
5
|
NA
|
NA
|
|
6.4.3
|
Extended
Planned Outage - Notification
|
Level
5
|
NA
|
NA
|
|
6.5.1
|
Processing
Time - Check Domain
|
Level
3
|
NA
|
NA
|
|
6.5.2
|
Processing
Time - Add/Create Domain
|
Level
3
|
NA
|
NA
|
|
6.5.3
|
Processing
Time - Modify/Update and Delete Domain
|
Level
3
|
NA
|
NA
|
|
6.5.4
|
Processing
Time - Whois Query
|
NA
|
NA
|
Level
3
|
|
6.5.5
|
Processing
Time - DNS Name Server Resolution
|
NA
|
Level
3
|
NA
|
|
6.6.1
|
Update
Frequency - DNS Name Server
|
NA
|
Level
4
|
NA
|
|
6.6.2
|
Update
Frequency - Whois
|
NA
|
NA
|
Level
4
|
2.1
Credit Level 1 - Credit Level 1 is assessed for DNS Name Server Service
Availability less than 100% per Monthly Timeframe. If the DNS Name Server Service
Availability Performance Specification is not met, the SLA Credit for Credit
Level 1 shall be payable to active ICANN-Accredited Registrars 30 days after
the applicable calendar month in which the Service Availability Performance
Specification was not met. For purposes of this Appendix 10, an
"active" ICANN-Accredited Registrar is one who has registered greater
than 150 net new .com domain names in the previous Monthly Timeframe.
Each
active ICANN-Accredited Registrar that meets the requirements of Section 3
below would be credited an amount equal to such active ICANN-Accredited
Registrar's net new .com domain name registrations during the applicable
Monthly Timeframe divided by the net amount of new .com domain name
registrations for all active ICANN-Accredited Registrars within the applicable
Monthly Timeframe times the Monthly Credit Amount set forth in Table Credit
Level 1.
Table
Credit Level 1
|
|
<30 sec.'s
|
30-60 sec.'s
|
1-2 min.'s
|
2-10 min.'s
|
10-30 min.'s
|
over 30 min.'s
|
|
SLA Credit Amount
|
$100,000
|
$175,000
|
$250,000
|
$400,000
|
$750,000
|
$1,000,000
|
2.2
Credit Level 2 - Credit Level 2 is assessed for SRS Service Availability less
than 99.99% per calendar year and for Whois Service Availability less than 100%
per Monthly Timeframe. If a Service Availability Performance Specification
metrics are not met, the SLA Credit for Credit Level 2 shall be credited
directly to active ICANN-Accredited Registrar(s) that meet the requirements of
Section 3 below in an amount equal to the duration of the outage times (OT)
times the average daily number of .com registrations over the previous three
(3) months (NRAvg) times the .com wholesale fee divided by the number of
minutes per day (1,440 minutes).
Active
ICANN-Accredited Registrar would be credited:
(.com Registry Fee)*(OT)*(NRAvg)
(1,440 minutes)
Additionally,
for any month where the total combined Unplanned Outage of SRS and Whois is
greater than 30 minutes, Registry Operator will credit active ICANN-Accredited
Registrars that meet the requirements of Section 3 below One Thousand Dollars
($1,000).
2.3
Credit Level 3 - Credit Level 3 is assessed for failure to meet the Performance
Specifications for the Processing Time for check domain, add/create,
modify/update and delete domain commands, and DNS Name Server Resolution and
Whois queries. If the Processing Time Performance Specifications metrics are
not met, the SLA Credit for Credit Level 3 (Refer to Table Credit Level 3)
shall be payable to active ICANN-Accredited Registrars in an amount based upon
the % of time that the Processing Time exceeds the applicable Performance
Specifications metric.
Each
active ICANN-Accredited Registrar that meets the requirements of Section 3
below would be credited an amount equal to such active ICANN-Accredited
Registrar's net new .com domain name registrations during the applicable
Monthly Timeframe divided by the net amount of net new .com domain name
registrations for all active ICANN-Accredited Registrars within the applicable
Monthly Timeframe times the SLA Credit Amount set forth in Table Credit Level 3
within 30 days after the applicable calendar month.
Table
Credit Level 3
|
|
5 - <10%
|
10 - <25%
|
25 - <50%
|
≥50%
|
|
SLA Credit Amount
|
$500
|
$1,000
|
$2,000
|
$5,000
|
2.4 Credit Level 4 - Credit Level 4 is assessed for failure to meet the
Performance Specifications for Update frequencies for DNS Name Server and
Whois. If the Update frequency Performance Specifications metrics are not met,
the SLA Credit for Credit Level 4 (Refer to Table Credit Level 4) shall be
payable to active ICANN-Accredited Registrars in an amount based upon the % of
time that the Update frequency exceeds the applicable Performance
Specifications metric.
Each
active ICANN-Accredited Registrar that meets the requirements of Section 3
below would be credited an amount equal to such active ICANN-Accredited
Registrar's net new .com domain name registrations during the applicable
Monthly Timeframe divided by the net amount of new .com domain name
registrations for all active ICANN-Accredited Registrars within the applicable
Monthly Timeframe times the SLA Credit Amount set forth in Table Credit Level
4.
Table
Credit Level 4
|
|
Up to <15 minutes over
|
15 minutes to <1 hour
|
1 hour to <12 hours
|
≥ 12 hours
|
|
SLA Credit Amount
|
$500
|
$1,000
|
$2,000
|
$5,000
|
2.5 Credit Level 5 - Credit Level 5 is assessed for failure to
meet the Performance Specifications for Planned Outage Timeframe, Planned
Outage Notification, Extended Planned Outage Timeframe and Extended Planned
Outage Notification. If the Performance Specifications metrics are not met, the
SLA Credit for Credit Level 5 shall be payable to each active ICANN-Accredited
Registrar that meets the requirements of Section 3 below in an amount equal to
such active ICANN-Accredited Registrar's net new .com domain name registrations
during the applicable Monthly Timeframe divided by the net amount of new .com
domain name registrations for all active ICANN-Accredited Registrars within the
applicable Monthly Timeframe times One Thousand Dollars ($1,000).
2.6
Credit Level 6 - Credit Level 6 is assessed for failure to meet the Performance
Specifications for Planned Outage Duration and Extended Planned Outage
Duration. If the Performance Specifications are not met, the SLA Credit for
Credit Level 6 shall be payable directly to active ICANN-Accredited
Registrar(s) that meet the requirements of Section 3 below in an amount equal
to the Average Daily Volume (ADM) of net .com new adds as averaged over the
course of the previous three months times the Planned Duration Overage (PDO) in
minutes times the SLA Credit graduated financial penalty set forth in Table
Credit Level 6. For purposes of this Appendix 10, PDO is calculated by
subtracting the maximum allowable time in hours and minutes for a Planned
Outage Duration or Extended Planned Outage Duration, as applicable, from the
total outage in hours and minutes.
Table
Credit Level 6
|
|
1 to <15 minutes
|
15 minutes to <1 hour
|
1 to <3 hours
|
3 –to <6 hours
|
≥ 6 hours
|
|
SLA Credit
|
ADM*PDO*$0.25
|
ADM*PDO*$0.5
|
ADM*PDO*$1
|
ADM*PDO*$1.50
|
ADM*PDO*$2
|
3.
Registrar Responsibilities.
In
order for ICANN-Accredited Registrars to claim SLA Credits outlined in this
Appendix 10, the procedures of this Section 3 must be strictly followed.
3.1
The affected ICANN-Accredited Registrar must report each occurrence of alleged
failure by Registry Operator to meet a Performance Specification and make a
request for SLA Credit to the Registry Operator's customer service help desk in
the manner required by the Registry Operator (i.e., e-mail, fax, telephone) in
order to be eligible for a SLA Credit. An affected ICANN Accredited Registrar
must initiate a request for SLA Credits within three months of the end of the
calendar year in which the failure to meet a Performance Specification
occurred.
3.2
Each ICANN-Accredited Registrar must inform the Registry Operator any time its
estimated volume of transactions (excluding check domain commands) is expected
to exceed the ICANN-Accredited Registrar's previous month's volume by more than
25%. In the event that an ICANN-Accredited Registrar fails to inform Registry
Operator of a forecasted increase of volume of transactions of 25% or more and
the ICANN-Accredited Registrar's volume increases 25% or more over the previous
month, and should the total volume of transactions for the Registry Operator
for all ICANN-Accredited Registrars for that month exceed the Registry
Operator's actual volume of the previous month's transactions by more than 20%,
then the ICANN-Accredited Registrar will not be eligible for any SLA Credits
outlined in this SLA in that Monthly Timeframe. An ICANN-Accredited Registrar
shall provide such forecast at least 30 days prior to the first day of the
applicable calendar month. Registry Operator agrees to provide monthly
transaction summary reports to ICANN-Accredited Registrars via e-mail.
3.3
The affected ICANN-Accredited Registrar must provide documentation to support
its claim for a SLA Credit. An ICANN-Accredited Registrar shall provide
documentation in the form of either:
a) ICANN-Accredited
Registrar initiated notification(s) to the Registry Operator of a Performance
Specification that exceeded SLA limits or failed to meet SLA requirements,
including the trouble ticket number issued by the Registry Operator. The
closing ticket(s) should be included as well in order to determine the total
downtime (unless the trouble ticket includes this); or
b)
Notification from the Registry Operator (with trouble ticket number attached)
of a Performance Specification that exceeded SLA limits or failed to meet SLA
requirements. The closing ticket(s) should be included as well in order to
determine the total downtime (unless the trouble ticket includes this).
3.4 In
order to calculate credits, the affected ICANN-Accredited Registrar must
include volume figures for the past three (3) calendar months (or, if less,
such amount of time that the ICANN-Accredited Registrar has been authorized to
register names in the .com registry) and a certification that these numbers
accurately reflect the minimum number of registrations that would be covered
during the affected period.
3.5
Registry Operator shall perform the required measurements in order to
corroborate the total SLA Credits requested by ICANN-Accredited Registrar. Such
measurements and associated documentation shall be delivered by e-mail to each
of the ICANN-Accredited Registrars requesting a SLA Credit.
3.6
When the above steps have been accurately completed, Registry Operator shall
provide notification of the number of SLA Credits that will be entered in the
affected ICANN-Accredited Registrar's account that can be used immediately
toward .com domain name registrations and other fees owed to Registry Operator
by the ICANN-Accredited Registrar.
4.
Obligations.
4.1
Except in the case of cross-network name server performance (which is not a
subject of this Service Level Agreement), Registry Operator will perform
monitoring from at least two external locations and a minimum of one internal
location as a means to verify that a) sessions can effectively be established
and b) EPP commands can be successfully completed.
4.2 In
the event that all ICANN-Accredited Registrars are affected by a SRS unavailability,
the Registry Operator is responsible for opening a blanket trouble ticket and
immediately notifying all ICANN-Accredited Registrars of the trouble ticket
number and details.
4.3 In
the event that the System Services are unavailable to an individual ICANN-Accredited
Registrar, Registry Operator will use commercially reasonable efforts to
re-establish the affected System Services for such ICANN-Accredited Registrar
as soon as reasonably practicable. Any System Services unavailability
attributable to any individual ICANN-Accredited Registrar that does not
represent a System Services outage will not result in SLA Credits or be subject
to this SLA.
4.4 ICANN-Accredited
Registrar(s) and the Registry Operator agree to use reasonable commercial good
faith efforts to establish the cause of any alleged System Services
unavailability. If it is mutually determined to be a Registry Operator problem,
the System Services unavailability will be subject to this SLA.
4.5
The Registry Operator will use commercially reasonable efforts to restore any
System Services within 24 hours after the termination of a force majeure event
and restore full system functionality within 48 hours after the termination of
a force majeure event. Outages due to a force majeure will not be considered
System Services unavailability, impact the Performance Specifications set forth
in Appendix 7, or be subject to this SLA.
4.6
The Registry Operator will open incident trouble tickets within a commercially
reasonable period of time and will treat all system performance problems in
order of decreasing severity and fix them within a commercially reasonable
period of time. Incidents flagged by the measurement system will also qualify
as ticketed events and will be subject to this SLA.
4.7
The Registry Operator will publish monthly system performance and Service
Availability reports.
5.
Miscellaneous.
5.1
This SLA is independent of any rights, obligations or duties set forth in the
Registry Agreement. In the event of any conflict between the terms and
conditions of this SLA and the Registry Agreement, the Registry Agreement shall
control.
5.2 As
an addendum to the Registry-Registrar Agreement ("RRA"), no provision
in this SLA is intended to replace any term or condition in the RRA.
5.3
Dispute Resolution will be handled per RRA Section 6.7.
5.4
Any interruption of System Services that occurs, as a direct result of RRA
Sections 2.13 (Resolution of Technical Problems or Breach of Agreement), 5.4
(Non-Payment of Fees), or 6.3 (Force Majeure) or any other applicable provision
within the RRA or Registry Operator's compliance with any Consensus Policy
established after the Effective Date, will not be subject to this SLA, but only
to the extent and for so long as such interruption of System Services is
unavoidable by commercially reasonable efforts due to Registry Operator's
compliance with such provisions within the RRA or any Consensus Policy
established after the Effective Date.
.com Registry Agreement Appendix 11
Public Interest Commitments
Registry Operator
agrees to perform the following public interest commitments.
a.
Registry
Operator will ensure that there is a provision in its Registry-Registrar
Agreement that requires registrars to include in their registration agreements
a provision prohibiting Registered Name Holders from distributing malware,
abusively operating botnets, phishing, piracy, trademark or copyright
infringement, fraudulent or deceptive practices, counterfeiting or otherwise
engaging in activity contrary to applicable law, and providing (consistent with applicable law and any related
procedures) consequences (to be enforced by the applicable registrar in
accordance with such registrar’s Registrar Accreditation Agreement) for such
activities, including suspension of the domain
name.
b.
Registry
Operator will periodically, but no less frequently than on a monthly basis,
conduct a technical analysis to assess whether domains in the TLD are being
used to perpetrate DNS Abuse. Registry Operator will maintain statistical
reports on identified DNS Abuse and the actions taken as a result of the
periodic technical analysis. Registry Operator will maintain these reports for
the current Term of the Agreement unless a
shorter period is required by law or approved by ICANN, and will provide
them to ICANN upon request.
c. DNS
Abuse Mitigation. Where Registry Operator reasonably determines, based on
actionable evidence, that a registered domain name in the TLD is being used for
DNS Abuse, Registry Operator must promptly take the appropriate mitigation
action(s) that are reasonably necessary to contribute to stopping, or otherwise
disrupting, the domain name from being used for DNS Abuse. Such action(s)
shall, at a minimum, include: (i) the referral of the domains being used for
the DNS Abuse, along with relevant evidence, to the sponsoring registrar; or
(ii) the taking of direct action, by Registry Operator, where Registry Operator
deems appropriate. Action(s) may vary depending on the circumstances of each
case, taking into account the severity of the harm from the DNS Abuse and the
possibility of associated collateral damage. For the purposes of this Agreement,
“DNS Abuse” is defined as malware, botnets, phishing, pharming, and spam (when
spam serves as a delivery mechanism for the other forms of DNS Abuse listed in
this definition) as those terms are defined in Section 2.1 of SAC115 (March 19,
2021) <https://www.icann.org/en/system/files/files/sac-115-en.pdf>).
d. Incident Reporting. Registry Operator
will give ICANN notice within seventy-two (72) hours of Registry Operator’s discovery of any
cyber incident, physical intrusion or infrastructure damages concerning the registry system for the
TLD that significantly jeopardizes, or is reasonably likely to significantly jeopardize,
the integrity, confidentiality or availability of the registry system such as significant:
accidental or unlawful
destruction, loss, alteration, unauthorized disclosure of, or access to registrar account information, registration data, DNSSEC
cryptographic private keys, or other information assets critical to the
operation of the registry system. The notice required pursuant to this Section
shall include, to the extent known by the Registry Operator after a reasonable
investigation, a detailed description of the cyber incident, physical intrusion
or infrastructure damages including how it occurred, the registry system
impacted, the likely impacts to registrars or registrants, if any, the number
of registrars, domain names, and registrants affected, and the actions taken by
Registry Operator in response to the cyber incident, physical intrusion or
infrastructure damages. If such information is not available initially,
Registry Operator shall provide such information when it becomes available
without undue delay. ICANN shall not disclose the notice given pursuant to this
Section in any manner, absent prior written consent from Registry Operator, or
except as required by law or necessary to preserve the security, stability and
resiliency of the Internet, in which case disclosure by ICANN shall be limited
to the relevant authority or authorities.
e. Network Ingress
Filtering. Registry Operator shall implement
network ingress filtering checks for its Registry Services as described in BCP
38 and BCP 84, which ICANN will also implement.
%20-%20for%20posting.fld/image001.png){kind=small}