.NET Registry Agreement
(1 July 2017)

REGISTRY AGREEMENT
This REGISTRY AGREEMENT (this "Agreement") is entered into as of 1 July 2017 by
and between Internet Corporation for Assigned Names and Numbers, a California
nonprofit public benefit corporation ("ICANN"), and VeriSign, Inc. a Delaware
corporation.
ARTICLE I INTRODUCTION
Section 1.1 Effective Date. The Effective Date for purposes of this Agreement
shall be 1 July 2017.
Section 1.2 Top-Level Domain. The Top-Level Domain to which this Agreement
applies is .net ("TLD").
Section 1.3 Designation as Registry Operator. Upon the Effective Date and
throughout the Term (as defined in Section 4.1 hereof) of this Agreement, unless
earlier terminated pursuant to Article 6 hereof, ICANN shall continue to
designate VeriSign, Inc. 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.

1

--------------------------------------------------------------------------------

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.

2

--------------------------------------------------------------------------------

(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 http://www.icann.org/en/general/consensus-policies.htm, 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 http://www.icann.org/en/general/consensus-policies.htm 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,

3

--------------------------------------------------------------------------------

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,

4

--------------------------------------------------------------------------------

the Consensus Polices 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, 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) 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. To this end, Registry Operator shall periodically deposit
into escrow all Registry Data on a schedule (not more frequently than weekly for
a complete set of Registry Data, and daily for incremental updates) and in an
electronic format mutually approved from time to time by Registry Operator and
ICANN, such approval not to be unreasonably withheld by either party. In
addition, Registry Operator will deposit into escrow that data collected from
registrars as part of offering Registry Services introduced after the Effective
Date of this Agreement. The schedule, content, format, and procedure for escrow
deposits shall be as reasonably established by ICANN from time to time, and as
set forth in Appendix 1 hereto. Changes to the schedule, content, format, and
procedure 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) above. The
escrow shall be held under 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. Notwithstanding the foregoing, the above language in this
Section 3.1(c)(i) shall expire and be of no further force

5

--------------------------------------------------------------------------------

and effect upon the later of August 1, 2017 or fifteen (15) days following the
execution by all parties of an Escrow Agreement substantially in the form of
Appendix 2A (Escrow Agreement), (hereinafter referred to as “Appendix 1A, 2A and
5A Effective Date”). Upon the Appendix 1A, 2A and 5A Effective Date: (1)
Appendix 1, Appendix 2, and Appendix 5 shall be deleted in their entirety and
replaced by Appendix 1A, 2A and 5A, respectively attached hereto; (2) Registry
Operator shall comply with the registry data escrow specifications set forth in
Appendix 1A; (3) the parties will comply with the executed Escrow Agreement
substantially in the form of Appendix 2A; and (4) Registry Operator shall comply
with Section 3(c)(v) below.
(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 shall provide bulk access to the
zone files for the registry for the TLD to ICANN on a continuous basis in the
manner ICANN may reasonably specify from time to time. Bulk access to the zone
files shall be provided to third parties on the terms set forth in the TLD zone
file access agreement reasonably established by ICANN, which initially shall be
in the form attached as Appendix 3 hereto. Notwithstanding the foregoing, upon
one hundred twenty (120) days from the Effective Date (“Appendix 3A Effective
Date”), Appendix 3 shall be deleted in its entirety and replaced with Appendix
3A and the Registry Operator will make available bulk access to zone files to
third parties in accordance with the terms of Appendix 3A. Changes to the zone
file access agreement may be made upon the mutual written consent of ICANN and
Registry Operator (which consent neither party shall unreasonably withhold).
(iv) Monthly Reporting. Within twenty (20) calendar days following the end of
each calendar month, Registry Operator shall prepare and deliver to ICANN a
report providing such data and in the format specified in Appendix 4. The
parties agree to negotiate in good faith to develop a transition plan within six
months of the Effective Date of this Agreement setting forth the timing and

6

--------------------------------------------------------------------------------

process by which Registry Operator will deliver the monthly operator’s reports
with the content and format set forth in Specification 3 of the new gTLD
registry agreement.
(v) Whois Service. Registry Operator shall provide such Whois data as set forth
in Appendix 5 until the Appendix 1A, 2A and 5A Effective Date. Upon the Appendix
1A, 2A and 5A Effective Date, Registry Operator shall provide Whois data as set
forth in Appendix 5A.
(d) Registry Operations.
(i) Registration Restrictions. Registry Operator shall reserve, and not register
any TLD strings (i) appearing on the list of reserved TLD strings attached as
Appendix 6 hereto or (ii) located
at http://data.iana.org/TLD/tlds-alpha-by-domain.txt for initial (i.e., other
than renewal) registration at the second level within the TLD.
(ii) Functional and Performance Specifications. Functional and Performance
Specifications for operation of the TLD shall be as set forth in Appendix 7
hereto, and shall address without limitation DNS services; operation of the
shared registration system; 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 .net registry as of the Effective Date, including as
set forth in Appendix 9, 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.
(iv) Process for Consideration of Proposed Registry Services. Following written
notification by Registry Operator to ICANN that Registry Operator may

7

--------------------------------------------------------------------------------

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.

8

--------------------------------------------------------------------------------

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

9

--------------------------------------------------------------------------------

(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

10

--------------------------------------------------------------------------------

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) Emergency Transition. The parties agree to negotiate in good faith to amend
this Agreement, including relevant appendices, if applicable, to incorporate an
emergency transition process for the operation of the registry for the TLD
within one hundred and twenty (120) days following the Effective Date. Such
emergency transition process shall include mutually agreed upon requirements for
ICANN's designation of an emergency interim registry operator of the registry
for the TLD and objective standards under which Registry Operator would resume
operation of the registry for the TLD.
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

11

--------------------------------------------------------------------------------

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.
3.3 Cooperation. The parties agree to cooperate with each other and share data
as necessary to accomplish the terms of this Agreement.
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

12

--------------------------------------------------------------------------------

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. This Agreement shall be effective on the Effective Date
through 30 June 2023 (the "Expiration Date"), subject to extension of such term
upon renewal pursuant to Section 4.2 (together, the initial and any renewal
terms shall constitute the “Term”). Registry Operator agrees that upon the
earlier of (i) termination of this Agreement by ICANN in accordance with Article
VI below or (ii) the Expiration Date, it will cease to be the Registry Operator
for the TLD, unless, with respect to termination under the foregoing clause
(ii), Registry Operator and ICANN agree on terms for renewal of the Agreement as
set forth in Section 4.2 below prior to the Expiration Date.
Section 4.2 Renewal. This Agreement shall be renewed upon the expiration of the
initial term set forth in Section 4.1 above and each renewal term of this
Agreement, 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. Upon renewal, Registry-Level
Transaction Fees may be reasonably modified so long as any increase in such fees
shall not exceed the average of the percentage increase in Registry-Level
Transaction Fees for the

13

--------------------------------------------------------------------------------

5 largest gTLDs (determined as above), during the prior three-year period. The
parties agree to initiate negotiations with respect to each renewal of the
Agreement at least six (6) months prior to the respective Expiration Date.
Section 4.3 Changes. While this Agreement is in effect, the parties agree to
engage in good faith negotiations at regular intervals (at least once every
three calendar years following the Effective Date) regarding possible changes to
the terms of the Agreement, including to Section 7.2 regarding fees and payments
to ICANN.
Section 4.4 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

14

--------------------------------------------------------------------------------

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 the amount of 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
fees, and monetary sanctions under Section 4.4, 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,

15

--------------------------------------------------------------------------------

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.4 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. ICANN may, upon notice to Registry Operator, terminate
this Agreement if (i) Registry Operator makes an assignment for the benefit of
creditors or similar act, (ii) attachment, garnishment or similar proceedings
are commenced against Registry Operator, which proceedings are a material threat
to Registry Operator’s ability to operate the registry for the TLD, and are not
dismissed within sixty (60) calendar days of their commencement, (iii) a
trustee, receiver, liquidator or equivalent is appointed in place of Registry
Operator or maintains control over any of Registry Operator’s property, (iv)
execution is levied upon any material property of Registry Operator that if
levied, would reasonably be expected to materially and adversely affect the
Registry Operator’s ability to operate the registry for the TLD, (v) proceedings
are instituted by or against Registry Operator under any bankruptcy, insolvency,
reorganization or other laws relating to the relief of debtors and such
proceedings are not dismissed within sixty (60) calendar days of their
commencement (if such proceedings are instituted by Registry Operator or its
Affiliates) or one hundred and eighty (180) calendar days of their commencement
(if such proceedings are instituted by a third party against Registry Operator),
or (vi) Registry Operator files for protection under

16

--------------------------------------------------------------------------------

the United States Bankruptcy Code, 11 U.S.C. Section 101 et seq., or a foreign
equivalent or liquidates, dissolves or otherwise discontinues its operations or
the operation of the TLD.
Section 6.3 Transition of Registry upon Termination of Agreement. Upon any
expiration of this Agreement as provided in Section 4.1 or 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(e), 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

17

--------------------------------------------------------------------------------

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) Special Programs. Notwithstanding Section 7.1(a), Registry Operator may for
the purpose of supporting the development of the Internet in an underserved
geographic region (a region being one or more countries) provide training,
technical support, marketing or incentive programs based on the unique needs of
registrars primarily focused on serving such geographies to such registrars, so
long as Registry Operator does not treat similarly situated registrars
differently or apply such programs arbitrarily. In addition, Registry Operator
may implement such programs with respect to registrars within a specific
geographic region (a region being one or more countries), so

18

--------------------------------------------------------------------------------

long as (i) such region is defined broadly enough to allow multiple registrars
to participate and such programs are made available to all such registrars, and
(ii) such programs do not favor any registrar in which Registry Operator may
have an ownership interest. For purposes of this section, an underserved
geographic region is one that, in the reasonable judgment of Registry Operator,
is underserved by registry operators based upon an analysis of relevant metrics,
including but not limited to broadband penetration, information and technology
expenditures, domain penetration, registrar penetration, web hosting
penetration, internet usage and number of internet users. Within five (5)
calendar days of offering any such programs, Registry Operator shall post a
notice of the offering of such program within the registrar facing communication
tools of Registry Operator’s website (which notice shall include, at a minimum,
the terms and conditions of such program and identify the underserved geographic
region underlying such program).
(c) 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.
(d) 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.
(e) 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,

19

--------------------------------------------------------------------------------

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 Transaction Fee. Registry Operator shall pay ICANN a
Registry-Level Transaction Fee in an amount equal to US$0.75 for each annual
increment of an initial or renewal domain name registration and for transferring
a domain name registration from one ICANN accredited registrar to another during
the calendar quarter to which the Registry-Level Transaction Fee pertains. ICANN
intends to apply this fee to purposes including: (a) a special restricted fund
for developing country Internet communities to enable further participation in
the ICANN mission by developing country stakeholders, (b) a special restricted
fund to enhance and facilitate the security and stability of the DNS, and (c)
general operating funds to support ICANN's mission to ensure the stable and
secure operation of the DNS; provided, that ICANN will not be required to
segregate funds for any such purpose or establish separate accounts for such
funds.
(b) Payment Schedule. Registry Operator shall pay the Registry-Level Fees
specified in Sections 7.2(a) and (c), and Section 7.2(d), if applicable, by the
20th day following the end of each calendar quarter (i.e., on April 20, July 20,
October 20 and January 20 for the calendar quarters ending March 31, June 30,
September 30 and December 31) of the year to an account designated by ICANN.
(c) Fixed Registry-Level Fee. Registry Operator shall pay ICANN a quarterly
Fixed Registry-Level Fee in an amount equal to US$37,950 for each quarter. Such
fee is subject to increase on July 1 of each year thereafter in an amount
established by ICANN's Board of Directors, but not to exceed a sum equal to 115%
of the prior year's fee. One dollar (USD) of the Fixed Registry-Level Fee shall
be waived for each dollar that the Registry-Level Transaction Fee exceeds
US$2,000,000 per annum.
(d) 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 fee will be calculated by ICANN, paid to ICANN by the

20

--------------------------------------------------------------------------------

Registry Operator in accordance with the Payment Schedule in Section 7.2(b), and
the Registry Operator will invoice and collect the fees from the registrars who
are party to a Registry-Registrar Agreement with Registry Operator. The 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 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 fiscal year.
(e) 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.
Section 7.3 Pricing for Domain Name Registrations and Registry Services.
(a) Pricing. The price to ICANN-accredited registrars for new and renewal domain
name registrations and for transferring a domain name registration from one
ICANN-accredited registrar to another, shall not exceed a total fee of US$8.95,
which fee consists of (A) a Registry Operator service fee ("Service Fee") equal
to US$8.20, and (B) an ICANN fee equal to US$0.75. The Service Fee charged
during a calendar year for each annual increment of a new and renewal domain
name registration and for transferring a domain name registration from one
ICANN-accredited registrar to another, shall not exceed the highest Service Fee
charged during the preceding calendar year multiplied by 1.10. The same Service
Fee shall be charged to all ICANN-accredited registrars. 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 are
available to all ICANN-accredited registrars. For the avoidance of doubt, the
programs expressly permitted by Section 7.1(b) shall not be a violation of this
Section 7.3(a).
(b) Adjustments to Pricing for Domain Name Registrations. Registry Operator
shall provide no less than six months prior notice in advance of any price
increase for domain name registrations and shall continue to offer domain name
registrations for periods of up to ten years.
ARTICLE VIII Miscellaneous
Section 8.1 Indemnification of ICANN.

21

--------------------------------------------------------------------------------

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

22

--------------------------------------------------------------------------------

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

23

--------------------------------------------------------------------------------

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 facsimile or
electronic mail as provided below, unless that party has given a notice of
change of postal or email address, or facsimile number, as provided in this
agreement. 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)
if via facsimile or by electronic mail, upon confirmation of receipt by the
recipient's facsimile machine or 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.

24

--------------------------------------------------------------------------------

If to ICANN, addressed to:
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
USA
Phone: +1 310 301 5800
FAX: +1 310 823 8649
Attention: President and CEO
With a Required Copy to: General Counsel
Email: (As specified from time to time.)
If to Registry Operator, addressed to:
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Telephone: 1-703-948-3200
Facsimile: 1-703-435-4921
Attention: General Counsel
Email: (As specified from time to time.)
Section 8.9 Language. Notices, designations, determinations, and specifications
made under this Agreement shall be in the English language.
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. 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]
 

25

--------------------------------------------------------------------------------

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:__/s/ Göran Marby______________
Göran Marby
President and Chief Executive Officer
Date: June 28, 2017    
 
VeriSign, Inc.
By:__/s/ D. James Bidzos___________
D. James Bidzos
President and Chief Executive Officer
Date: June 28, 2017    

26

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 1
Data Escrow Specification
(Effective 1 July 2017 until the Appendix 1A, 2A and 5A Effective Date)

This Appendix 1 to the .net Registry Agreement consists of four of the five
exhibits to the Data Escrow Agreement that constitutes Appendix 2 to the TLD
Registry Agreement:
Exhibit A-Schedule for Escrow Deposits
Exhibit B-Escrow Deposit Format Specification
Exhibit C-Escrow Transfer Process
Exhibit D-Escrow Verification Procedures
The fifth exhibit (Exhibit E), which sets forth Escrow Agent's fees, is subject
to negotiation between Registry Operator and Escrow Agent.
EXHIBIT A
Schedule for Escrow Deposits
Weekly and daily deposits will include records/transactions generated just
before 00:00:00 (EST/EDT) of the next day they relate, e.g., report related to
Sunday will include all transactions generated just before 00:00:00 of the
following Monday. Date fields will be date-time data expressed in Eastern
Standard Time / Eastern Daylight Time using the Gregorian calendar, e.g.
"2010-03-29T18.04.32" until a future time, to be mutually agreed by the Parties,
when the date fields will include a time zone indicator specifically
corresponding to the Eastern Standard Time / Eastern Daylight Time, as
appropriate, e.g. "2010-03-29T18.04.32-04:00" Data fields in the specified
reports will be colon delimited until a future time, to be mutually agreed by
the parties, when the delimiter will be changed to a tilde "~" or other agreed
delimiter. Further, the Registrar Whois Report from the Weekly Deposit Materials
will be provided in XML.
Weekly Escrow Deposits:
VNDS will deposit a complete set of Data into escrow on a weekly basis by
electronically and securely transmitting a snapshot of each operational
Registrar's data (the "Deposit Materials"). The snapshot captures the state of
each Registrar's data at the time the snapshot was created. Specific data
elements contained in the Deposit Materials are identified in Table 1 of Exhibit
B.

--------------------------------------------------------------------------------

Daily Escrow Deposits:
VNDS will securely and electronically deposit a transaction log for each
operational Registrar representing transactions that occurred over the previous
24-hour period (the "Additional Deposit"). The logs will be escrowed daily,
being in the form of Additional Deposit each Tuesday through Sunday, and being
in the form of the Weekly Deposit Materials each Monday, which shall capture
that Sunday's data. The Daily Additional Deposit will act as incremental updates
to the Weekly Deposit Materials and will include all Registrar activity, such as
add, delete, and transfer of a domain name. Specific data elements contained in
the Additional Deposit are identified in Table 2 of Exhibit B.
Electronic Delivery Service Escrow Deposit Method:
The transmitted data will be made available to Data Escrow Provider as follows:
Daily Deposits:
Daily transactional data will be made available no later than 18:00 (EDT/EST)
each Tuesday through Sunday for the previous calendar day. For example,
transactional data related to Monday would be available to the escrow company on
Tuesday no later than 18:00 (EDT/EST). The results of transactions completed on
Sunday will be made available in the Weekly Deposit Materials, thus no separate
Daily Additional Deposit will be made for Sunday activity.
Weekly Deposits:
Weekly database snapshots taken at midnight on Sundays will be available not
later than 18:00 (EDT/EST) each Monday.
EXHIBIT B
ESCROW DEPOSIT FORMAT SPECIFICATION
Each Weekly and Daily Deposit consists of a series of reports that are
concatenated in the escrow process.
Table 1: Weekly Deposit Materials Format
Weekly Reports
1. Registrar Domain Report - com
Title: Registrar Domain Report - com
Report name: rgr_domain_com
Description: This report contains data for domains sponsored by all registrars.
Status Information will use Status Values from RFC 5731, Section 2.3. Since a
domain may have more than one status, each domain will have separate lines for
each domain/nameserver/status combination.

--------------------------------------------------------------------------------

Fields:
Domain Name (domainname)
Server names for all nameservers (servername)
IANA Registrar ID (registrarid)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
Domain ROID (roid)
2. Registrar Nameserver Report
Title: Registrar Nameserver Report
Report name: rgr_nameserver
Description: This report contains data for all nameservers sponsored by all
registrars. The nameserver is listed once with all associated information. Since
a nameserver may have more than one IP address, each nameserver will have
separate lines for each nameserver/IP address/status combination. Status
Information will use Status Values from RFC 5732, Section 2.3.
Fields:
Server Name (servername)
IP Address (ipaddress)
IANA Registrar ID (registrarid)
Updated Date (updatedate)
Creation Date (createdate)
Expiration Date (expirationdate)
Status Information (statusname)
Nameserver ROID (nsroid)
3. Registrar Whois Report
Title: Registrar Whois Report
Report name: registrar_whois
Description: This report contains data for registrars sponsoring registered
domains and nameservers and will consist of one record for each registrar.
Fields:
IANA Registrar ID (REGISTRARID)
Registrar Name (REGISTRARNAME)
Address 1 (ADDRESSLINE1)
Address 2 (ADDRESSLINE2)
Address 3 (ADDRESSLINE3)

--------------------------------------------------------------------------------

City (CITY)
State / Province (STATEPROVINCE)
Postal Code (POSTALCODE)
Country (COUNTRYCODE)
Telephone Number (PHONENUMBER)
Fax Number (FAXNUMBER)
E-Mail Address (EMAIL)
Whois Server (WHOISSERVER)
Web URL (URL)
Updated Date (UPDATEDATE)
Administrative Contact First Name(ADMINFNAME)
Administrative Contact Last Name (ADMINLNAME)
Administrative Contact Telephone Number (ADMINPHONE)
Administrative Contact E-Mail (ADMINEMAIL)
Billing Contact First Name (BILLINGFNAME)
Billing Contact Last Name (BILLINGLNAME)
Billing Contact Telephone Number (BILLINGPHONE)
Billing Contact E-Mail (BILLINGEMAIL)
Technical Contact First Name (TECHFNAME)
Technical Contact Last Name (TECHLNAME)
Technical Contact Telephone Number (TECHPHONE)
Technical Contact E-Mail (TECHEMAIL)
4. Domain Name Registrant Data
If VNDS requires registrars to provide it with registrant domain name
registration data, VNDS shall escrow such registrant domain name registration
data that is collected from registrars.
5. DNSSEC-Related Data
At such time that VNDS implements DNSSEC and collects DS records, VNDS shall
escrow such DS records.
Title: DS Report
Report name: ds_domain_report_com
Description: This report contains delegation signer (DS) records associated with
domains sponsored by all registrars. Each DS record is listed once.
Fields:
Domain Name (domainname)
Domain ROID (roid)
Key Tag (keytag)
Algorithm (algorithm)

--------------------------------------------------------------------------------

Digest Type (digesttype)
Digest (digest)
DS records will be escrowed in DS RR Presentation Format as defined in section
5.3 of RFC 4034.
6. Registry Services Data
VNDS shall escrow data collected from registrars as part of offering Registry
Services introduced after the Effective Date of its Registry Agreement with
ICANN, if any.
Table 2: Daily Additional Deposit Format
Registrar Daily Additional Deposits
1. Registrar Transaction Report
Title: Registrar Transaction Report
Report name: rgr_transaction
Description: This report contains transactions associated with a specific
registrar. Domain operations produce one row for each associated nameserver.
Nameserver operations produce one row for each associated ipaddress. If multiple
DS records are associated with a transacton, those records will be comma
separated and included on a single line with that transaction. A transactionid
is included to allow unique identification of transactions. Operations of type
"MOD" (e.g., MOD_DOMAIN, MOD_NAMESERVER, itc.) will include all the associated
objects even if they were not affected by the transaction, i.e., a MOD_DOMAIN
operation will include a row for each nameserver even for those that were not
modified. The content of columns 3 and 4 is dependent on the operation in the
following ways:
operation Œ (ADD_DOMAIN, MOD_DOMAIN, DEL_DOMAIN) => [domainname][servername]
operation Œ (ADD_NAMESERVER, MOD_ NAMESERVER, DEL_ NAMESERVER) =>
[ipaddress][servername]
operation Œ (TRANSFER_DOMAIN) => [domainname][null]
operation Oe (ADD_DS, MOD_ DS, DEL_ DS) => [domainname][dsdata]
Only the seven (7) operation types above are included in the report.
The dsdata column will have the following fields in DS RR Presentation Format as
defined in section 5.3 of RFC 4033 with pipe delimiter for -
<KeyTag>|<Algorithm>|<DigestType>|<Digest>
Fields:
transactionid
operationname

--------------------------------------------------------------------------------

domainname | ipaddress
servername | null
transactiondate
roid
dsdata | null
EXHIBIT C
Escrow Transfer Process
Effective: To Be Mutually Agreed Between VNDS and Data Escrow Provider
Deposit Transfer Process. Registry Operator shall prepare and transfer the
Deposit file by the following steps, in sequence:
1. The Reports making up the Deposit will first be created according to the
format specification. (See Exhibit B above, "Escrow Deposit Format
Specification").
2. The Reports making up the Deposit will be concatenated. The resulting file
shall be named according to the following format: "com-SEQN-YYYYMMDD", where
"SEQN" is a four digit decimal number that is incremented as each report is
prepared and "YYYY" represents the year, "MM" the month, and "DD" the day of the
date to which the file relates.
3. Next, the Deposit files will be processed by a program (provided by ICANN)
that will verify that it complies with the format specification and contains
reports of the same date/time (for a Full Deposit), count the number of objects
of the various types in the Deposit, and append to the file a report of the
program's results.
4. Registry Operator may optionally split the resulting file using the Unix
SPLIT command (or equivalent) to produce files no less than 1 GB each (except
the final file). If Deposit files are split, a .MD5 file (produced with MD5SUM
or equivalent) must be included with the split files to isolate errors in case
of transfer fault.
5. The Deposit file(s) will then be encrypted using Escrow Agent's public key
for GPG or PGP and signed using Registry Operator's private key for GPG or PGP,
both version 6.5.1 or above, with a key of DH/DSS type and 2048/1024-byte
length. (Note that GPG or PGP compresses the Deposit file(s) in addition to
encrypting it (them).)
The formatted, encrypted and signed Deposit file(s) will be sent, by anonymous
file transfer, to Escrow Agent's SFTP server within the specified time window.

--------------------------------------------------------------------------------

Significant changes to the escrow transfer process require extensive integration
between the parties. To ensure the registry data is always protected via the
escrow process, Registry Operator will continue to run the legacy escrow
transfer process and the new escrow transfer process in parallel until such time
as all parties agree to retire the legacy escrow transfer process. The legacy
escrow process will escrow all data listed in Exhibit B.
EXHIBIT D
Escrow Verification Procedures
Effective: To Be Mutually Agreed Between VNDS and Data Escrow Provider
Verification Procedures. Escrow Agent will verify the format and completeness of
each Deposit by the following steps:
1. At the conclusion of the deposit window, all Deposit files will be moved to a
not-publicly-accessible directory and the existence and size of each will be
noted.
2. Each Deposit file will be decrypted using Escrow Agent's private key for GPG
or PGP and authenticated using Registry Operator's public key for GPG or PGP.
(In this step, GPG or PGP will also automatically decompress the escrow file).
3. If there are multiple files, they will be concatenated in sequence.
4. Escrow Agent will run a program (to be supplied by ICANN) on the Deposit
files (without report) that will split it in to its constituent reports
(including the format report prepared by the Registry Operator and appended to
the Deposit) check its format, count the number of objects of each type, and
verify that the data set is internally consistent. This program will compare its
results with the results of the Registry-generated format report, and will
generate a Deposit format and completeness report. The program will encrypt the
report using ICANN's public key for GPG or PGP and signed using Escrow Agent's
private key for GPG or PGP, both versions 6.5.1 or above, with a key of DH/DSS
type and 2048/1024-byte length. (Note that GPG or PGP compresses the Deposit
file(s) in addition to encrypting it (them). Escrow Agent will send the
encrypted and signed report to ICANN by email.
5. The decrypted Deposit files will be destroyed to reduce likelihood of data
loss to intruders in case of partial security failure.
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. 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, Sponsor and ICANN shall exchange keys by the same
procedure.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 1A
Data Escrow Specification
(Effective as of the Appendix 1A, 2A and 5A Effective Date)
 
As of the Appendix 1A, 2A and 5A Effective Date, Registry Operator will engage
an independent entity to act as data escrow agent (“Escrow Agent”) for the
provision of data escrow services related to the Agreement pursuant to an
agreement substantially in the form of Appendix 2A, 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. The escrow
shall be held under an agreement, substantially in the form of Appendix 2A, as
the same may be revised from time to time, among ICANN, Registry Operator, and
the Escrow Agent.
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
draft-arias-noguchi-registry-data-escrow, see Section 9, reference 1 of this
Appendix and draft-arias-noguchi-dnrd-objects-mapping, 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.  If not already an
RFC, Registry Operator will use the most recent draft version of the DNDE
Specification available at the Effective Date.  Registry Operator may at its
election use newer versions of the DNDE Specification after the Effective Date. 
Once the DNDE Specification is published as an RFC, Registry Operator will
implement that version of the DNDE Specification, no later than one hundred
eighty (180) calendar days after.  UTF-8 character encoding will be used. 

3.2
Extensions.  If 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 2.1 of Appendix 5A;

4)
"thick-{gurid}", if the data represents Thick Registration Data from a specific
registrar, as defined in Section 2.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”:

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 at the Effective Date.  Registry Operator may at
its election use newer versions of the Interface Specification after the
Effective Date.  Once the Interface Specification is published as an RFC,
Registry Operator will implement that version of the Interface Specification, no
later than one hundred eighty (180) calendar days after such publishing.
8. Verification Procedure.
1)
The signature file of each processed file is validated.

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

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

4)
Each data file contained in the previous step is then validated against the
format defined in 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)
Domain Name Data Escrow Specification (work in progress),
http://tools.ietf.org/html/draft-arias-noguchi-registry-data-escrow

--------------------------------------------------------------------------------

2)
Domain Name Registration Data (DNRD) Objects Mapping,
http://tools.ietf.org/html/draft-arias-noguchi-dnrd-objects-mapping

3)
OpenPGP Message Format, http://www.rfc-editor.org/rfc/rfc4880.txt

4)
OpenPGP parameters,
http://www.iana.org/assignments/pgp-parameters/pgp-parameters.xhtml

5)
ICANN interfaces for registries and data escrow agents,
http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 2
Escrow Agreement
(Effective 1 July 2017 until the Appendix 1A, 2A and 5A Effective Date)

This Escrow Agreement ("Agreement") is made as of this 30 day of June, 2009, by
and between VeriSign, Inc. ("Registry Operator"), Iron Mountain Intellectual
Property Management, Inc. ("Escrow Agent"), and the Internet Corporation for
Assigned Names and Numbers ("ICANN").
Preliminary Statement. Registry Operator intends to deliver the "Deposit
Materials" and any "Additional Deposit" to Escrow Agent as defined and provided
for herein. Registry Operator desires Escrow Agent to hold the Deposit Materials
and, upon certain events described herein, deliver the Deposit Materials (or a
copy thereof) to ICANN in accordance with the terms hereof.
Escrow Agent certifies that it is allowed to receive the Deposit under the UK
Data Protection Act as a registered data controller and/or is certified under
the European Union Safe Harbour Act.
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 Deposit Materials, as defined and described
in the "Data Escrow Specification," attached as Appendix 1 to the .net Registry
Agreement between Registry Operator and ICANN (the "Registry Agreement") and
incorporated herein by reference ("Appendix 1"). Registry Operator may elect to
deliver the Deposit Materials in accordance with Exhibit C to Appendix 1 or in a
manner mutually agreed upon by Escrow Agent and Registry Operator. Upon receipt
of the Deposit Materials, Escrow Agent shall immediately process the Deposit
Materials in accordance with Exhibit D of Appendix 1 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 them, Escrow Agent shall
verify that any Deposit Materials are in the proper format and appear to be
complete by performing the verification procedures specified in Exhibit D of
Appendix 1. Escrow Agent and Registry Operator agree that Escrow Agent will
verify the Deposit Materials using a program that may be provided by ICANN
("Scripts"). Escrow Agent shall deliver, on the last business

--------------------------------------------------------------------------------

day of each month, a written certification to ICANN that it has performed the
verification procedures described in Exhibit D on all Deposit Materials received
during the last month and shall deliver to ICANN a copy of the verification
reports generated by those procedures. If Escrow Agent discovers that any
Deposit Materials fail the verification procedures, Escrow Agent shall notify
ICANN and Registry Operator of such nonconformity within forty-eight (48) hours.
Escrow Agent shall then hold the Deposit Materials in accordance with the terms
and conditions hereof.
2. Duplication; Periodic Updates
(a) Escrow Agent may duplicate the Deposit Materials by any means in order to
comply with the terms and provisions of this Agreement. Alternatively, Escrow
Agent, by notice to Registry Operator, may reasonably require Registry Operator
to promptly duplicate the Deposit Materials and forward the same to Escrow
Agent.
(b) Registry Operator shall deposit with Escrow Agent the "Additional Deposit,"
as defined and described in the attached Exhibit A of Appendix 1. Within two (2)
business days after receiving them, Escrow Agent shall verify that any
Additional Deposits are in the proper format and appear to be complete by
performing the verification procedures specified in Exhibit D of Appendix 1.
Escrow Agent shall deliver, on the last business day of each month, a written
certification to ICANN that it has performed those verification procedures on
all Additional Deposits received during the last month and shall deliver to
ICANN a copy of the verification reports generated by those procedures. If
Escrow Agent discovers that any Additional Deposits fail the verification
procedures, Escrow Agent shall notify ICANN and Registry Operator of such
nonconformity within forty-eight (48) hours.
3. Notification of Deposits. Simultaneous with the delivery to Escrow Agent of
the Deposit Materials or any Additional Deposit, as the case may be, Registry
Operator shall deliver to Escrow Agent a written statement, via email,
specifically identifying all items deposited and stating that the Deposit
Materials and/or any Additional Deposit have been inspected by Registry Operator
and are complete and accurate. Escrow Agent shall, within two (2) business days
of receipt of any Deposit Materials or Additional Deposit, send notification to
Registry Operator and ICANN, via email, that it has received from Registry
Operator such Deposit Materials and/or any such Additional Deposit. In addition,
Escrow Agent shall also include a copy of the processing report as confirmation
that it has completed processing the deposit.
4. Delivery by Escrow Agent

--------------------------------------------------------------------------------

4.1 Delivery by Escrow Agent to ICANN. Escrow Agent shall deliver the Deposit
Materials and any Additional Deposits received since the last submission of
Deposit Material ("Outstanding Additional 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 check payable 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 between Registry Operator
and ICANN dated March 1, 2006 ("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 Deposit Materials and Outstanding Additional
Deposits be released and delivered to ICANN;
(iv) a written undertaking from ICANN that the Deposit Materials and Outstanding
Additional 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 check from Registry Operator, or from ICANN (who will then be reimbursed
by Registry Operator), payable to Escrow Agent in the amount of one hundred
dollars ($100.00); or
(c) Release occurs according to Paragraph 8(b) below.
4.2 Delivery at Registry Operator's Request. If the provisions of 4.1(a) are
satisfied, Escrow Agent shall, within five (5) business days after receipt of
the notification and check specified in Paragraph 4.1(a), deliver the Deposit
Materials and Outstanding Additional Deposits in accordance with the applicable
instructions.
4.3 Delivery at ICANN's Request. If the provisions of Paragraphs 4.1(b) or
4.1(c) are satisfied, Escrow Agent within five (5) business days after receipt
of all the documents specified in these paragraphs, shall deliver the following:
(i) to Registry Operator, a photostatic copy of all such documents; (ii) to
ICANN, as specifically instructed by ICANN, electronic copies of the Deposit
Materials and

--------------------------------------------------------------------------------

electronic copies of the Outstanding Additional Deposits; provided, however,
that if the delivery is commenced by reason of Paragraph 4.1 (c), Registry
Operator may make the payment owing to Escrow Agent during the five (5) business
day period referenced above, and Escrow Agent shall not thereafter deliver to
ICANN the materials specified in subpart (ii), above. Following receipt of the
notice to Registry Operator under subpart (i) of the preceding sentence,
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 Deposit Materials to
ICANN and request that the issue of entitlement to a copy of the Deposit
Materials be submitted to arbitration in accordance with the following
provisions:
(a) The sending of an Objection Notice shall not delay delivery of Deposit
Materials and Outstanding Additional 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 Paragraph 4.3(b), the parties agree that any arbitration
brought pursuant to Paragraph 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
Paragraph 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 Paragraph 4.3. Any arbitration
proceeding brought pursuant to Paragraph 4.3

--------------------------------------------------------------------------------

shall be limited to a determination of whether Paragraphs 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 Deposit Materials and Outstanding Additional
Deposits to ICANN in accordance with the instructions provided by ICANN.
(e) If the release of materials to ICANN pursuant to Paragraph 4.3 is judged to
be proper in any arbitration brought in accordance with Paragraph 4.3, Escrow
Agent shall promptly deliver to ICANN, in accordance with the instructions
specified in Paragraph 4.1(b)(v) above, any Deposit Materials and Outstanding
Additional Deposits that have not previously been delivered. All parties agree
that Escrow Agent shall not be required to deliver such Deposit Materials and
Outstanding Additional Deposits until all such fees then due to Escrow Agent
have been paid.
(f) If the release of the Deposit Materials and Outstanding Additional Deposits
to ICANN pursuant to Paragraph 4.3 is judged to have been improper in any
arbitration brought in accordance with Paragraph 4.3, ICANN shall promptly
return or destroy, at Registry Operator's discretion, those Deposit Materials
and Outstanding Additional Deposits that were received by ICANN pursuant to
Paragraph 4.3.
4.4 Delivery by Escrow Agent to Registry Operator. Escrow Agent shall release
and deliver the Deposit Materials and any Additional Deposit to Registry
Operator upon termination of this Agreement in accordance with Paragraph 7(a) or
7(b) hereof.
5. Indemnity.
(a) General Indemnity. Subject to the limitation imposed under Section 11(a),
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 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 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 Paragraph 4 and the parties under this Agreement submit the matter to such
arbitration as described in Paragraph 4 of this 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 Agreement shall be two (2) years, commencing on the
date hereof (the "Initial Term"). This Agreement shall be automatically extended
for an additional term of one year ("Additional Term") at the end of the Initial
Term and at the end of each Additional Term hereunder. Escrow Agent acting alone
or Registry Operator, with the concurrence of ICANN, may terminate this
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 Paragraph 7(a), and ICANN fails to concur according to Paragraph
7(a), ICANN shall be responsible for payment of all subsequent fees in
accordance with Exhibit E and shall have the right to seek reimbursement of such
fees from Registry Operator and to terminate this Agreement at any time upon
giving the other parties ninety (90) days notice.
(c) In the event of termination of this Agreement in accordance with Paragraph
7(a) or 7(b) hereof, Registry Operator shall pay all fees due Escrow Agent and
shall promptly notify ICANN that this Agreement has been terminated and that

--------------------------------------------------------------------------------

Escrow Agent shall return to Registry Operator all copies of the Deposit
Materials and any Additional Deposit then in its possession.
8. Fees. Registry Operator shall pay to Escrow Agent the applicable fees in
accordance with Exhibit E as compensation for Escrow Agent's services under this
Agreement. The first year's fees are due upon receipt of the signed contract or
Deposit Materials, whichever comes first, and shall be paid in U.S. Dollars.
(a) Invoice Payment. After acceptance, 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.
(b) 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 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 Paragraph 8(b) by either Registry
Operator or ICANN, or by Registry Operator under 4.3, the Escrow Agent shall
proceed as set forth in Paragraph 4.3 as though ICANN had requested delivery of
the Deposit Materials.
(c) Invoice Submission Address. During the term of this Agreement, Escrow Agent
agrees to submit detailed and timely invoices, not more frequently than once a
month, and not later than ninety (90) days after the work performed under such
invoice has been completed, to Registry Operator at the address set forth below
as described herein. All invoices issued hereunder shall reference the Purchase
Order number assigned to the work performed under this Agreement and the
Exhibits hereto. 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.
487 E. Middlefield Road
Mountain View , CA 94043
Attn: Accounts Payable
Or Invoices may be submitted electronically to:
accountspayable@verisign.net
9. Ownership of Deposit Materials. The parties recognize and acknowledge that
ownership of the Deposit Materials during the effective term of this Agreement
shall remain with Registry Operator at all times.
10. Retention and Confidentiality.
(a) Retention. Escrow Agent shall hold and maintain the Deposit Materials 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 Deposit Materials. Each of
ICANN and Registry Operator shall have the right to inspect Escrow Agent's
written records with respect to this Agreement upon reasonable prior notice and
during normal business hours.
(b) Confidentiality. Escrow Agent shall at all times protect the confidentiality
of the Deposit Materials. Except as provided in this Agreement, Escrow Agent
shall not disclose, transfer, make available, or use any Deposit Materials (or
any copies of any Deposit Materials). Should Escrow Agent be put on notice that
it is required to disclose any Deposit Materials 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(b) of this 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 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 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 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 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 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
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 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 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 Agreement, including all exhibits hereto, 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. All exhibits attached to Appendix 1 of the
Registry Agreement, specifically, Exhibits A through D are by this reference
made a part of this Agreement and are incorporated herein.
(g) Counterparts; Governing Law. This 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
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
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 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 Agreement by notice in
writing to the other parties as provided herein.
(i) Survival. Paragraphs 5, 6, 8, 9, 10 and 11 shall survive any termination of
this 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 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 Agreement as of the date and year first above written.
Iron Mountain Intellectual Property Management, Inc.
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

VeriSign, Inc.
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________
_____________________________________

--------------------------------------------------------------------------------

_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

Internet Corporation for Assigned Names and Numbers
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
 
See Appendix 1 to the Registry Agreement for Exhibits A through D to this
Agreement.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 2A
Escrow Agreement
(Effective as of the Appendix 1A, 2A and 5A Effective Date)

This Escrow Agreement ("Escrow Agreement") is made as of the Appendix 1A, 2A and
5A Effective Date, by and between VeriSign, Inc. ("Registry Operator"), Iron
Mountain Intellectual Property Management, Inc. ("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 to the .net Registry
Agreement between Registry Operator and ICANN (the "Registry Agreement") and
incorporated herein by this reference ("Appendix 1A"). Registry Operator may
elect to deliver the Deposits to Escrow Agent in accordance with Appendix 1A 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 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. 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 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. Escrow Agent shall, within two (2)
business days of receipt of any Deposit, send notification to Registry Operator
either by email, facsimile or telephone, or as may be otherwise requested by
Registry Operator, and to ICANN electronically using the API described in
http://tools.ietf.org/html/draft-lozano-icann-registry-interfaces 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 check payable 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 check from Registry Operator, or from ICANN (who will then be reimbursed
by Registry Operator), payable to Escrow Agent in the amount of one hundred
dollars ($100.00); or
(c) a release occurs according to Section 8(b) below.
4.2 Delivery at Registry Operator's Request. If the provisions of Section 4.1(a)
above are satisfied, Escrow Agent shall, within five (5) business days 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 five (5) business days 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 five (5)
business day 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 date hereof
and continue until June 30, 2023 (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. Registry Operator shall pay to Escrow Agent the applicable fees as
compensation for Escrow Agent's services under this Escrow Agreement. The first
year's fees are due upon receipt of the signed contract or Deposits, whichever
comes first, and shall be paid in U.S. Dollars.
(a) Invoice Payment. After acceptance, 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.
(b) 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(b) 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.
(c) Invoice Submission Address. During the term of this Escrow Agreement, Escrow
Agent agrees to submit detailed and timely invoices, not more frequently than
once a month, and not later than ninety (90) days after the work performed under
such invoice has been completed, to Registry Operator at the address set forth
below as described herein. 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.net
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 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(b)
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 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 date and year first above written.
Iron Mountain Intellectual Property Management, Inc.
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________
_____________________________________
_____________________________________

--------------------------------------------------------------------------------

_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

VeriSign, Inc.
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

Internet Corporation for Assigned Names and Numbers
By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:
 
_____________________________________

--------------------------------------------------------------------------------

_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
 

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 3
Zone File Access Agreement
(Effective 1 July 2017 until the Appendix 3A Effective Date)

1. PARTIES
The User named in this Agreement hereby contracts with VeriSign, Inc. ("VNDS")
for a non-exclusive, non-transferable, limited right to access an Internet host
server or servers designated by VNDS from time to time, and to transfer a copy
of the described Data to the User's Internet host machine specified below, under
the terms of this Agreement. Upon execution of this Agreement by VNDS, VNDS will
return a copy of this Agreement to you for your records with your UserID and
Password entered in the spaces set forth below.
2. USER INFORMATION
(a) User: __________________________________________
(b) Contact Person: _________________________________
(c) Street Address: __________________________________
(d) City, State or Province: ____________________________
(e) Country and Postal Code: __________________________
(f) Telephone Number: _______________________________
(including area/country code)
(g) Fax Number: ____________________________________
(including area/country code)
(h) E-Mail Address: _________________________________
(i) Specific Internet host machine which will be used to access VNDS's server to
transfer copies of the Data:
Name: ___________________________________________
IP Address: _______________________________________
(j) Purpose(s) for which the Data will be used: During the term of this
Agreement, you may use the data for any legal purpose, not prohibited under
Section 4 below. You may incorporate some or all of the Data in your own

--------------------------------------------------------------------------------

products or services, and distribute those products or services for a purpose
not prohibited under Section 4 below.
3. TERM
This Agreement is effective for a period of three (3) months from the date of
execution by VNDS (the "Initial Term"). Upon conclusion of the Initial Term,
this Agreement will automatically renew for successive three-month renewal terms
(each a "Renewal Term") until terminated by either party as set forth in Section
12 of this Agreement or one party provides the other party with a written notice
of termination at least seven (7) days prior to the end of the Initial Term or
the then current Renewal Term.
NOTICE TO USER: CAREFULLY READ THE FOLLOWING TERMS AND CONDITIONS. YOU MAY USE
THE USER ID AND ASSOCIATED PASSWORD PROVIDED IN CONJUNCTION WITH THIS AGREEMENT
ONLY TO OBTAIN A COPY OF .NET TOP-LEVEL DOMAIN ("TLD") ZONE FILES, AND ANY
ASSOCIATED ENCRYPTED CHECKSUM FILES (COLLECTIVELY THE "DATA"), VIA THE FILE
TRANSFER PROTOCOL ("FTP") OR HYPERTEXT TRANSFER PROTOCOL ("HTTP") PURSUANT TO
THESE TERMS.
4. GRANT OF ACCESS
VNDS grants to you a non-exclusive, non-transferable, limited right to access an
Internet host server or servers designated by VNDS from time to time, and to
transfer a copy of the Data to the Internet host machine identified in Section 2
of this Agreement no more than once per 24 hour period without the express prior
written consent of VNDS using FTP or HTTP for the purposes described in this
Section 4. You agree that you will:
(a) use this Data only for lawful purposes but that under no circumstances will
you use this Data to: (1) allow, enable, or otherwise support any marketing
activities, regardless of the medium used. Such media include but are not
limited to e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts;
or (2) enable high volume, automated, electronic processes that send queries or
data to the systems of VNDS or any ICANN-accredited registrar, except as
reasonably necessary to register domain names or modify existing registrations.
VNDS reserves the right, with the approval of the Internet Corporation for
Assigned Names and Numbers ("ICANN"), to specify additional specific categories
of prohibited uses by giving you reasonable written notice at any time and upon
receiving such notice you shall not make such prohibited use of the Data you
obtain under this Agreement.

--------------------------------------------------------------------------------

(b) copy the Data you obtain under this Agreement into a machine-readable or
printed form only as necessary to use it in accordance with this Agreement in
support of your use of the Data.
(c) comply with all applicable laws and regulations governing the use of the
Data.
(d) not distribute the Data you obtained under this Agreement or any copy
thereof to any other party without the express prior written consent of VNDS,
except that you may redistribute the Data insofar as it has been incorporated by
you into a value-added product or service that does not permit the extraction of
a substantial portion of the Data from the value-added product or service,
provided you prohibit the recipient of the Data from using the Data in a manner
contrary to Section 4(a).
(e) take all reasonable steps to protect against unauthorized access to, use,
and disclosure of the Data you obtain under this Agreement.
5. FEE
You agree to remit in advance to VNDS a quarterly fee of $0 (USD) for the right
to access the files during either the Initial Term or Renewal Term of this
Agreement. VNDS reserves the right to adjust, with the approval of ICANN, this
fee on thirty days' prior notice to reflect a change in the cost of providing
access to the files.
6. PROPRIETARY RIGHTS
You agree that no ownership rights in the Data are transferred to you under this
Agreement. You agree that any copies of the Data that you make will contain the
same notice that appears on and in the Data obtained under this Agreement.
7. METHOD OF ACCESS
VNDS reserves the right, with the approval of ICANN, to change the method of
access to the Data at any time. You also agree that, in the event of significant
degradation of system processing or other emergency, VNDS may, in its sole
discretion, temporarily suspend access under this Agreement in order to minimize
threats to the operational stability and security of the Internet.
8. NO WARRANTIES
The Data is being provided "as-is." VNDS disclaims all warranties with respect
to the Data, either expressed or implied, including but not limited to the
implied warranties of merchantability, fitness for a particular purpose, and
non-infringement of third party rights. Some jurisdictions do not allow the
exclusion

--------------------------------------------------------------------------------

of implied warranties or the exclusion or limitation of incidental or
consequential damages, so the above limitations or exclusions may not apply to
you.
9. SEVERABILITY
In the event of invalidity of any provision of this Agreement, the parties agree
that such invalidity shall not affect the validity of the remaining provisions
of this Agreement.
10. NO CONSEQUENTIAL DAMAGES
In no event shall VNDS be liable to you for any consequential, special,
incidental or indirect damages of any kind arising out of the use of the Data or
the termination of this Agreement, even if VNDS has been advised of the
possibility of such damages.
11. GOVERNING LAW
This Agreement shall be governed and construed in accordance with the laws of
the Commonwealth of Virginia, USA. You agree that 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 only in the state or
federal courts in Fairfax County and the Eastern District of the Commonwealth of
in Virginia, USA. You expressly and irrevocably agree and consent to the
personal jurisdiction and venue of the federal and states courts located
Virginia, USA (and each appellate court located therein) for matters arising in
connection with this Agreement or your obtaining, use, or distribution of the
Data. The United Nations Convention on Contracts for the International Sale of
Goods is specifically disclaimed.
12. TERMINATION
You may terminate this Agreement at any time by erasing the Data you obtained
under this Agreement from your Internet host machine together with all copies of
the Data and providing written notice of your termination to VNDS at 12061
Bluemont Way, Reston, VA 20190, Attention: Customer Service. VNDS has the right
to terminate this Agreement immediately if you fail to comply with any term or
condition of this Agreement. You agree upon receiving notice of such termination
of this Agreement by VNDS or expiration of this Agreement to erase the Data you
obtained under this Agreement together with all copies of the Data.
13. DEFINITION
"Data" means all data contained in a DNS zone file for the Registry TLD as
provided to TLD nameservers on the Internet.

--------------------------------------------------------------------------------

14. ENTIRE AGREEMENT
This is the entire agreement between you and VNDS concerning access and use of
the Data, and it supersedes any prior agreements or understandings, whether
written or oral, relating to access and use of the Data.
VeriSign, Inc.
By: (sign)
Name: (print)
Title:
Date:
User:
By: (sign)
Name: (print)
Title:
Date:
ASSIGNED USERID AND PASSWORD
(To be assigned by VNDS upon execution of this Agreement):
USERID:
PASSWORD:

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 3A
Zone File Access Agreement
(Effective as of the Appendix 3A Effective Date)

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 below;
(b) Registry Operator may reject the request for access of any user that does
not provide correct or legitimate credentials under Section 1.2 below or where
Registry Operator reasonably believes will violate the terms of Section 1.5.
below; and, (c) Registry Operator may revoke access of any user if Registry
Operator has evidence to support that the user has violated the terms of Section
1.5 below.
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.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 4
Monthly Operators Reports
(1 July 2017)

Registry Operator shall provide the following information for .NET in three
monthly reports as described below. Reports shall be submitted via email to
<registry-reports@icann.org>. ICANN may request in the future that the reports
be delivered by other means. ICANN shall use reasonable commercial efforts to
preserve the confidentiality of the information reported until three months
after the end of the month to which the report relates.
(A) Monthly Report. File shall be in Portable Document Format (PDF). Report
shall contain the following information:
1. Accredited Registrar Status. State the number of registrars in each of the
following three categories: (1) operational, (2) ramp-up (registrars that have
received a password for access to OT&E), and (3) pre-ramp-up (registrars that
have requested access, but have not yet entered the ramp-up period).
2. Service Level Agreement Performance. Compare Service Level Agreement
requirements with actual performance measures for the reporting month.
3. TLD Zone File Access Activity. State the total number of zone file access
passwords at end of the reporting month.
4. Completed System Software Releases. Describe significant releases during the
reporting month, including release name, features, and completion date.
5. Whois Service Activity. State the number of Whois queries during the
reporting month.
6. Total Number of Transactions by Subcategory by Month. State the total number
of transactions during the reporting month, in the following subcategories:
adds, deletes, modifies, checks, renews, transfers, restores.
7. Daily Transaction Range. Tabulate the number of total daily transactions. The
range of transaction volume should be shown for each month, along with the
average daily transaction volume.

--------------------------------------------------------------------------------

(B) Per-Registrar Activity Report. File shall be named
"net-transactions-YYYYMM.csv"; where "YYYYMM" is the year and month being
reported. This report shall be in comma separated-value format as specified in
RFC 4180, using the following fields per registrar:
Field #
Field Name
Notes
1
registrar-name
registrar's full corporate name
2
iana-id
http://www.iana.org/assignments/registrar-ids/
3
total-domains
total domains under sponsorship
4
total-nameservers
total nameservers registered
5
net-adds-1-yr
domains successfully added (and not deleted within the add grace period)
6
net-adds-2-yr
number of domains successfully registered with an initial term of two years (and
not deleted within the add grace period)
7
net-adds-3-yr
number of domains successfully registered with an initial term of three years
(and not deleted within the add grace period)
8
net-adds-4-yr
etc.
9
net-adds-5-yr
" "
10
net-adds-6-yr
" "
11
net-adds-7-yr
" "
12
net-adds-8-yr
" "
13
net-adds-9-yr
" "
14
net-adds-10-yr
" "
15
net-renews-1-yr
domains renewed either automatically or by command (and not deleted within the
renew grace period)
16
net-renews-2-yr
number of domains successfully renewed with a new renewal period of two years
(and not deleted within the renew grace period)
17
net-renews-3-yr
number of domains successfully renewed with a new renewal period of three years
(and not deleted within the renew grace period)
18
net-renews-4-yr
etc.
19
net-renews-5-yr
" "

--------------------------------------------------------------------------------

20
net-renews-6-yr
" "
21
net-renews-7-yr
" "
22
net-renews-8-yr
" "
23
net-renews-9-yr
" "
24
net-renews-10-yr
" "
25
transfer-gaining-successful
transfers initiated by this registrar that were ack'd by the other registrar -
either by command or automatically
26
transfer-gaining-nacked
transfers initiated by this registrar that were n'acked by the other registrar
27
transfer-losing-successful
transfers initiated by another registrar that this registrar ack'd - either by
command or automatically
28
transfer-losing-nacked
transfers initiated by another registrar that this registrar n'acked
29
transfer-disputed-won
number of transfer disputes in which this registrar prevailed
30
transfer-disputed-lost
number of transfer disputes this registrar lost
31
transfer-disputed-nodecision
number of transfer disputes involving this registrar with a split or no decision
32
deleted-domains-grace
domains deleted within the add grace period
33
deleted-domains-nograce
domains deleted outside the add grace period
34
restored-domains
domain names restored from redemption period
35
restored-noreport
total number of restored names for which the registrar failed to submit a
restore report
36
agp-exemption-requests
total number of AGP (add grace period) exemption requests
37
agp-exemptions-granted
total number of AGP (add grace period) exemption requests granted
38
agp-exempted-domains
total number of names affected by granted AGP (add grace period) exemption
requests
39
attempted-adds
number of attempted (successful and failed) domain name create commands

--------------------------------------------------------------------------------

The first line shall include the field names exactly as they appear in the table
above as a "header line" as described in section 2 of RFC 4180. The last line of
each report should 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 "CRLF" as described in RFC 4180.
(C) 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
"net-activity-yyyymm.csv", where "yyyymm" is the year and month being reported.
The file shall contain the following fields:

Field #
Field Name
Description
1
operational-registrars
number of operational registrars at the end of the reporting period
2
ramp-up-registrars
number of registrars that have received a password for access to OT&E at the end
of the reporting period
3
pre-ramp-up-registrars
number of registrars that have requested access, but have not yet entered the
ramp-up period at the end of the reporting period
4
zfa-passwords
number of active zone file access passwords at the end of the reporting period
5
whois-43-queries
number of WHOIS (port-43) queries responded during the reporting period
6
web-whois-queries
number of Web-based Whois queries responded during the reporting period, not
including searchable Whois
7
searchable-whois-queries
number of searchable Whois queries responded during the reporting period, if
offered
8
dns-udp-queries-received
number of DNS queries received over UDP transport during the reporting period
9
dns-udp-queries-responded
number of DNS queries received over UDP transport that were responded during the
reporting period
10
dns-tcp-queries-received
number of DNS queries received over TCP transport during the reporting period

--------------------------------------------------------------------------------

11
dns-tcp-queries-responded
number of DNS queries received over TCP transport that were responded during the
reporting period
12
srs-dom-check
number of SRS (EPP and any other interface) domain name "check" requests
responded during the reporting period
13
srs-dom-create
number of SRS (EPP and any other interface) domain name "create" requests
responded during the reporting period
14
srs-dom-delete
number of SRS (EPP and any other interface) domain name "delete" requests
responded during the reporting period
15
srs-dom-info
number of SRS (EPP and any other interface) domain name "info" requests
responded during the reporting period
16
srs-dom-renew
number of SRS (EPP and any other interface) domain name "renew" requests
responded during the reporting period
17
srs-dom-rgp-restore-report
number of SRS (EPP and any other interface) domain name RGP "restore" requests
delivering a restore report responded during the reporting period
18
srs-dom-rgp-restore-request
number of SRS (EPP and any other interface) domain name RGP "restore" requests
responded during the reporting period
19
srs-dom-transfer-approve
number of SRS (EPP and any other interface) domain name "transfer" requests to
approve transfers responded during the reporting period
20
srs-dom-transfer-cancel
number of SRS (EPP and any other interface) domain name "transfer" requests to
cancel transfers responded during the reporting period
21
srs-dom-transfer-query
number of SRS (EPP and any other interface) domain name "transfer" requests to
query about a transfer responded during the reporting period
22
srs-dom-transfer-reject
number of SRS (EPP and any other interface) domain name "transfer" requests to
reject transfers responded during the reporting period
23
srs-dom-transfer-request
number of SRS (EPP and any other interface) domain name "transfer" requests to
request transfers responded during the reporting period
24
srs-dom-update
number of SRS (EPP and any other interface) domain name "update" requests (not
including RGP restore requests) responded during the reporting period
25
srs-host-check
number of SRS (EPP and any other interface) host "check" requests responded
during the reporting period
26
srs-host-create
number of SRS (EPP and any other interface) host "create" requests responded
during the reporting period
27
srs-host-delete
number of SRS (EPP and any other interface) host "delete" requests responded
during the reporting period

--------------------------------------------------------------------------------

28
srs-host-info
number of SRS (EPP and any other interface) host "info" requests responded
during the reporting period
29
srs-host-update
number of SRS (EPP and any other interface) host "update" requests responded
during the reporting period
30
srs-cont-check
number of SRS (EPP and any other interface) contact "check" requests responded
during the reporting period
31
srs-cont-create
number of SRS (EPP and any other interface) contact "create" requests responded
during the reporting period
32
srs-cont-delete
number of SRS (EPP and any other interface) contact "delete" requests responded
during the reporting period
33
srs-cont-info
number of SRS (EPP and any other interface) contact "info" requests responded
during the reporting period
34
srs-cont-transfer-approve
number of SRS (EPP and any other interface) contact "transfer" requests to
approve transfers responded during the reporting period
35
srs-cont-transfer-cancel
number of SRS (EPP and any other interface) contact "transfer" requests to
cancel transfers responded during the reporting period
36
srs-cont-transfer-query
number of SRS (EPP and any other interface) contact "transfer" requests to query
about a transfer responded during the reporting period
37
srs-cont-transfer-reject
number of SRS (EPP and any other interface) contact "transfer" requests to
reject transfers responded during the reporting period
38
srs-cont-transfer-request
number of SRS (EPP and any other interface) contact "transfer" requests to
request transfers responded during the reporting period
39
srs-cont-update
number of SRS (EPP and any other interface) contact "update" requests responded
during the reporting period

The first line shall include the field names exactly as described in the table
above as a "header line" as described in section 2 of RFC 4180. 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.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 5
Whois Specifications
(Effective 1 July 2017 until the Appendix 1A, 2A and 5A Effective Date)

Public Whois Specification
Registry Operator's Whois service is the authoritative Whois service for all
second-level Internet domain names registered in the.NET top-level domain and
for all hosts registered using these names. This service is available to anyone.
It is available via port 43 access and via links at the Registry Operator's web
site. It is updated daily.
To use Registry Whois via port 43 enter the applicable parameter on the command
line as illustrated below:
For a domain name: whois "domain verisign.net"
For a registrar name: whois "registrar Go Daddy Software, Inc."
For a nameserver: whois "DNS3.REGISTER.NET" or whois "nameserver 216.21.234.72"
By default, Whois performs a very broad search, looking in all record types for
matches to your query in these fields: domain name, nameserver name, nameserver
IP address, and registrar names. Use keywords to narrow the search (for example,
'domain root'). Specify only part of the search string to perform a "partial"
search on domain. Every domain starting with the string will be found. A
trailing dot (or dots) after your text or the partial keyword indicates a
partial search. For example, entering 'mack.' will find "Mack", "Mackall",
"Mackay", and so on.
To use Registry Whois using the web interface:
Go to www.verisign-grs.net/whois
Click on the appropriate button ("domain," "registrar" or "nameserver")
Enter the applicable parameter:
Domain name including the TLD (e.g., verisign-grs.net)
Full name of the registrar including punctuation, "Inc.", etc. (e.g., America
Online, Inc.)
Full host name or the IP address (e.g., ns1.crsnic.net or 198.41.3.39)

--------------------------------------------------------------------------------

Click on the "submit" button.
For all registered second-level domain names in .NET, information as illustrated
in the following example is displayed in a thin format, where the entry
parameter is the domain name (including the TLD):
Domain Name: VERISIGN-GRS.NET
Registrar: NETWORK SOLUTIONS, LLC.
Whois Server: whois.networksolutions.com
Referral URL: http://www.networksolutions.com/
Name Server: NS1.CRSNIC.NET
Name Server: NS2.NSIREGISTRY.NET
Name Server: NS3.VERISIGN-GRS.NET
Name Server: NS4.VERISIGN-GRS.NET
Status: REGISTRAR-LOCK
Updated Date: 20-oct-2004
Creation Date: 08-sep-2000
Expiration Date: 08-sep-2008
>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<
For all ICANN-accredited registrars who are authorized to register .net
second-level domain names through Registry Operator, information as illustrated
in the following example is displayed, where the entry parameter is the full
name of the registrar (including punctuation, "Inc.", etc.):
Registrar Name: SAMPLE REGISTRAR, INC. DBA SAMPLE NAMES
Address: 1234 Any Way, Anytown, VA 20153, US
Phone Number: 703-555-5555
Email: registrar-agent@samplenames.net
Whois Server: whois.registrar.samplenames.net
Referral URL: www.registrar.samplenames.net
Admin Contact: Jane Doe
Phone Number: 703-555-5556
Email: janedoe@samplenames.net
Admin Contact: John Smith
Phone Number: 703-555-5557
Email: johnsmith@samplenames.net
Admin Contact: Domain Name Administrator
Phone Number: 703-555-5558
Email: dns-eng@samplenames.net
Billing Contact: Petranella Jones
Phone Number: 703-555-5559
Email: pjones@samplenames.net

--------------------------------------------------------------------------------

Technical Contact: Harry Nerd
Phone Number: 703 555-6000
Email: harrynerd@samplenames.net
Technical Contact: Harry Nerd II
Phone Number: 703-555-6001
Email: harrynerd@samplenames.net
>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<
For all hosts registered using second-level domain names in .NET, information as
illustrated in the following example is displayed, where the entry parameter is
either the full host name or the IP address:
Server Name: DNS.MOMINC.NET
IP Address: 209.143.112.34
Registrar: BULKREGISTER, LLC.
Whois Server: whois.bulkregister.net
Referral URL: http://www.bulkregister.net/
>>> Last update of whois database: Wed, 2 Feb 2005 07:52:23 EST <<<
Whois Provider Data Specification
Registry Operator shall provide bulk access to up-to-date data concerning domain
name and nameserver registrations maintained by Registry Operator in connection
with the Registry TLD on a daily schedule, only for purposes of providing free
public query-based access to up-to-date data concerning domain name and
nameserver registrations in multiple TLDs, to a party designated from time to
time in writing by ICANN. The specification of the content and format of this
data, and the procedures for providing access, shall be as stated below, until
changed according to the Registry Agreement.
Content
The data shall be provided in three files:
A. Domain file. One file shall be provided reporting on the domains sponsored by
all registrars. For each domain, the file shall give the domainname, servername
for each nameserver, registrarid, and updateddate.
B. Nameserver file. One file shall be provided reporting on the nameservers
sponsored by all registrars. For each registered nameserver, the file shall give
the servername, each ipaddress, registrarid, and updateddate.
C. Registrar file. A single file shall be provided reporting on the registrars
sponsoring registered domains and nameservers. For each registrar, the following
data elements shall be given: registrarid, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,

--------------------------------------------------------------------------------

updateddate and the name, telephone number, and e-mail address of all the
registrar's administrative, billing, and technical contacts.
Format
The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.
Procedures for Providing Access
The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator. In the absence of an agreement, the files shall be
provided by Registry Operator sending the files in encrypted form to the party
designated by ICANN by Internet File Transfer Protocol.
Whois Data Specification - ICANN
Registry Operator shall provide bulk access by ICANN to up-to-date data
concerning domain name and nameserver registrations maintained by Registry
Operator in connection with the .NET TLD on a daily schedule, only for purposes
of verifying and ensuring the operational stability of Registry Services and the
DNS. The specification of the content and format of this data, and the
procedures for providing access, shall be as stated below, until changed
according to the Registry Agreement.
Content
The data shall be provided in three files:
A. Domain file. One file shall be provided reporting on the domains sponsored by
all registrars. For each domain, the file shall give the domainname, servername
for each nameserver, registrarid, and updateddate.
B. Nameserver file. One file shall be provided reporting on the nameservers
sponsored by all registrars. For each registered nameserver, the file shall give
the servername, each ipaddress, registrarid, and updateddate.
C. Registrar file. A single file shall be provided reporting on the registrars
sponsoring registered domains and nameservers. For each registrar, the following
data elements shall be given: registrarid, registrar address, registrar
telephone number, registrar e-mail address, whois server, referral URL,
updateddate and the name, telephone number, and e-mail address of all the
registrar's administrative, billing, and technical contacts.
Format
The format for the above files shall be as specified by ICANN, after
consultation with Registry Operator.

--------------------------------------------------------------------------------

Procedures for Providing Access
The procedures for providing daily access shall be as mutually agreed by ICANN
and Registry Operator. In the absence of an agreement, an up-to-date version
(encrypted using a public key supplied by ICANN) of the files shall be placed at
least once per day on a designated server and available for downloading by ICANN
by Internet File Transfer Protocol.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 5A
Whois Specifications
(Effective as of the Appendix 1A, 2A and 5A Effective Date)

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

Registry Operator shall implement a new standard supporting access to domain
name registration data (SAC 051) no later than one hundred thirty-five (135)
days after it is requested by ICANN if: 1) the IETF produces a standard (i.e.,
it is published, at least, as a Proposed Standard RFC as specified in RFC 2026);
and 2) its implementation is commercially reasonable in the context of the
overall operation of the registry.
1.1.    The format of responses shall follow a semi-free text format outline
below, followed by a blank line and a legal disclaimer specifying the rights of
Registry Operator, and of the user querying the database.
1.2.    Each data object shall be represented as a set of key/value pairs, with
lines beginning with keys, followed by a colon and a space as delimiters,
followed by the value.
1.3.    For fields where more than one value exists, multiple key/value pairs
with the same key shall be allowed (for example to list multiple name servers).
The first key/value pair after a blank line should be considered the start of a
new record, and should be considered as identifying that record, and is used to
group data, such as hostnames and IP addresses, or a domain name and registrant
information, together.
1.4.    The fields specified below set forth the minimum output requirements.
Registry Operator may output data fields in addition

--------------------------------------------------------------------------------

to those specified below, subject to approval by ICANN, which approval shall not
be unreasonably withheld.
1.5. Domain Name Data:
1.5.1      Query format: whois EXAMPLE.TLD
1.5.2 Response format:
Domain Name: EXAMPLE.TLD
Domain ID: D1234567-TLD
WHOIS Server: whois.example.tld
Referral URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Sponsoring Registrar: EXAMPLE REGISTRAR LLC
Sponsoring Registrar IANA ID: 5555555
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX

--------------------------------------------------------------------------------

Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.6. Registrar Data:
1.6.1 Query format: whois “registrar Example Registrar, Inc.”
1.6.2 Response format:
Registrar Name: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
Email: registrar@example.tld
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213

--------------------------------------------------------------------------------

Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.7. Nameserver Data:
1.7.1     Query format: whois “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.
WHOIS Server: whois.example-registrar.tld
Referral URL: http://www.example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.8.    The format of the following data fields: domain status, individual and
organizational names, address, street, city, state/province, postal code,
country, telephone and fax numbers (the extension will be provided as a separate
field as shown above), email addresses, date and times should conform to the
mappings specified in EPP RFCs 5730-5734 so that the display of this information
(or values return in WHOIS responses) can be uniformly processed and understood.
1.9.    In order to be compatible with ICANN’s common interface for WHOIS
(InterNIC), WHOIS output shall be in the format outline above.

--------------------------------------------------------------------------------

1.10.     Searchability. Offering searchability capabilities on the Directory
Services is optional but if offered by the Registry Operator it shall comply
with the specification described in this section.
1.10.1     Registry Operator will offer searchability on the web-based Directory
Service.
1.10.2     Registry Operator will offer partial match capabilities, at least, on
the following fields: domain name, contacts and registrant’s name, and contact
and registrant’s postal address, including all the sub-fields described in EPP
(e.g., street, city, state or province, etc.).
1.10.3     Registry Operator will offer exact-match capabilities, at least, on
the following fields: Registrar ID, name server name, and name server’s IP
address (only applies to IP addresses stored by the registry, i.e., glue
records).
1.10.4     Registry Operator will offer Boolean search capabilities supporting,
at least, the following logical operators to join a set of search criteria: AND,
OR, NOT.
1.10.5     Search results will include domain names matching the search
criteria.
1.10.6     Registry Operator will: 1) implement appropriate measures to avoid
abuse of this feature (e.g., permitting access only to legitimate authorized
users); and 2) ensure the feature is in compliance with any applicable privacy
laws or policies.
1.11.     Registry Operator shall provide a link on the primary website for the
TLD (i.e., the website provided to ICANN for publishing on the ICANN website) to
a web page designated by ICANN containing WHOIS policy and educational
materials.
2.    Bulk Registration Data Access to ICANN
2.1     Periodic Access to Thin Registration Data. In order to verify and ensure
the operational stability of Registry Services as well as to facilitate
compliance checks on accredited registrars, Registry Operator will provide ICANN
on a weekly basis (the day to be designated by ICANN) with up-to-date
registration data as specified below. Data will include data committed as of
00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.

--------------------------------------------------------------------------------

2.1.1     Contents. Registry Operator will provide, at least, the following data
for all registered domain names: domain name, domain name repository object id
(roid), Registrar ID (IANA ID), statuses, last updated date, creation date,
expiration date, and name server names. For sponsoring registrars, at least, it
will provide: registrar name, Registrar ID (IANA ID), hostname of registrar
Whois server, and URL of registrar.
2.1.2     Format. The data will be provided in the format specified in Appendix
1A 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. Registry
Operator has the option to provide a Full Deposit file instead as specified in
Appendix 1A.
2.1.3     Access. Registry Operator will have the file(s) ready for download as
of 00:00:00 UTC on the day designated for retrieval by ICANN. The file(s) will
be made available for download by SFTP, though ICANN may request other means in
the future.
2.2     Exceptional Access to Thick Registration Data. In case of a registrar
failure, deaccreditation, court order, etc. that prompts the temporary or
definitive transfer of its domain names to another registrar, at the request of
ICANN, Registry Operator will provide ICANN with up-to-date data for the domain
names of the losing registrar. The data will be provided in the format specified
in Appendix 1A 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 2.1 of this Appendix.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 6
Schedule of Reserved Names
(1 July 2017)

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.
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:
nic
whois
www

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 7
Functional and Performance Specifications
(1 July 2017)

These functional specifications for the Registry TLD consist of the following
parts:
1.
Standards Compliance;

2.
Supported initial and renewal registration periods;

3.
Grace period policy;

4.
Wildcard Prohibition;

5.
Patch, update, and upgrade policy;

6.
Performance Specifications;

7.
Responsibilities of the Parties; and

8.
Additional Services

1. Standards Compliance

1.1 DNS. Registry Operator shall comply with relevant existing RFCs and those
published in the future by the Internet Engineering Task Force (IETF), including
all successor standards, modifications or additions thereto relating to the DNS
and name server operations for RFCs 1034, 1035, 1123, 1982, 2181, 2182, 3226,
3596, 3597, 4343, 5966 and 6891. DNS labels may only include hyphens in the
third and fourth position if they represent valid IDNs (as specified above) in
their ASCII encoding (e.g., “xn--ndk061n”).
1.2 EPP. Registry Operator shall comply with relevant existing RFCs and those
published in the future by the Internet Engineering Task Force (IETF) including
all successor standards, modifications or additions thereto relating to the
provisioning and management of domain names using the Extensible Provisioning
Protocol (EPP) in conformance with RFCs 5910, 5730, 5731, 5732 (if using host
objects), 5733 and 5734. Notwithstanding the foregoing, nothing herein shall
require Registry Operator to comply with informational RFCs with respect to EPP
under this Section 1.2 of Appendix 7. If Registry Operator implements Registry
Grace Period (RGP), it will comply with RFC 3915 and its

--------------------------------------------------------------------------------

successors. If Registry Operator requires the use of functionality outside the
base EPP RFCs, Registry Operator is not required to submit documented EPP
extensions to the IETF but Registry Operator must document EPP extensions in
Internet-Draft format following the guidelines described in RFC 3735. Registry
Operator will provide and update the relevant documentation of all the EPP
Objects and Extensions supported to ICANN prior to deployment.
1.3 DNSSEC. Registry Operator shall sign its TLD zone files implementing Domain
Name System Security Extensions (“DNSSEC”). For the absence of doubt, Registry
Operator shall sign the zone file of <TLD> and zone files used for in-bailiwick
glue for the TLD’s DNS servers. During the Term, Registry Operator shall comply
with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best
practices described in RFC 6781 and its successors. If Registry Operator
implements Hashed Authenticated Denial of Existence for DNS Security Extensions,
it shall comply with RFC 5155 and its successors. Registry Operator shall accept
public-key material from 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. DNSSEC validation must be
active and use the IANA DNS Root Key Signing Key set (available at
https://www.iana.org/dnssec/files) as a trust anchor for Registry Operator’s
Registry Services making use of data obtained via DNS responses.
1.4 IDN. If the Registry Operator offers Internationalized Domain Names
(“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors.
Registry Operator shall comply with the ICANN IDN Guidelines at
<http://www.icann.org/en/topics/idn/implementation-guidelines.htm>, as they may
be amended, modified, or superseded from time to time. Registry Operator shall
publish and keep updated its IDN Tables and IDN Registration Rules in the IANA
Repository of IDN Practices.
1.5 IPv6. Registry Operator shall be able to accept IPv6 addresses as glue
records in its Registry System and publish them in the DNS. Registry Operator
shall offer public IPv6 transport for, at least, two of the Registry’s name
servers listed in the root zone with the corresponding IPv6 addresses registered
with IANA. Registry Operator should follow “DNS IPv6 Transport Operational
Guidelines” as described in BCP 91 and the recommendations and considerations
described in RFC 4472. Registry Operator shall offer public IPv6 transport for
its Registration Data Publication Services as defined in Appendix 4

--------------------------------------------------------------------------------

of this Agreement; e.g., Whois (RFC 3912), Web based Whois. Registry Operator
shall offer public IPv6 transport for its Shared Registration System (SRS) to
any Registrar, no later than six (6) months after receiving the first request in
writing from a gTLD accredited Registrar willing to operate with the SRS over
IPv6.
1.6 IANA Rootzone Database. 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 or WHOIS records of the TLD. Registry Operator shall use
commercially reasonable efforts to submit any such change request no later than
seven (7) calendar days after the date any such DNS or WHOIS records becomes
outdated or inaccurate. Registry Operator must submit all change requests in
accordance with the procedures set forth at <http://www.iana.org/domains/root>.
1.7 Network Ingress Filtering. Registry Operator shall implement network ingress
filtering checks for its Registry Services as described in BCP 38 and BCP 84,
which ICANN will also implement.
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 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 the 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 registration 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

•
Restore 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 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 registration 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.
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
registrars' 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 that 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 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. Wildcard Prohibition
For domain names which are either not registered, or the registrant has not
supplied valid records such as NS records for listing in the DNS zone file, or
their status does not allow them to be published in the DNS, the use of DNS
wildcard Resource Records as described in RFCs 1034 and 4592 or any other method
or technology for synthesizing DNS Resources Records or using redirection within
the DNS by the Registry is prohibited. When queried for such domain names the
authoritative name servers must return a "Name Error" response (also known as
NXDOMAIN), RCODE 3 as described in RFC 1035 and related RFCs. This provision
applies for all DNS zone files at all levels in the DNS tree for which the
Registry Operator (or an affiliate engaged in providing Registration Services)
maintains data, arranges for such maintenance, or derives revenue from such
maintenance 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.
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 below. 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 a Registry-Registrar Agreements in effect with Registry Operator for the
Registry TLD and who have registered greater than 150 net new .net 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 5.
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 VeriSign 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
Registrars 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 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 this 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 metric for DNS Name Server is Credit Level 4.
6.6.2 Update Frequency--Whois
Update Frequency-Whois = 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 a Monthly
Timeframe. Cross-network name server performance measurements may be conducted
by ICANN at 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 .net DNS Name Servers
and observing the responses from the .net 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 .net 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 .net name server must not exceed the required values;
6.7.3.2 The packet loss to each of the .net 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 .net 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 5.
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 Abuse Mitigation
7.6.1 Abuse Contact. Registry Operator shall provide to ICANN and publish on its
website its accurate contact details including a valid email and mailing address
as well as a primary contact for handling inquiries related to malicious conduct
in the TLD, and will provide ICANN with prompt notice of any changes to such
contact details.
7.6.2 Malicious Use of Orphan Glue Records. Registry Operator shall take action
to remove orphan glue records (as defined at http://www.icann.org/en/

--------------------------------------------------------------------------------

committees/security /sac048.pdf) when provided with evidence in written form
that such records are present in connection with malicious conduct.
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 dot-NET 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.

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 8
.NET Registry-Registrar Agreement
(5 July 2012)

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 Information Services, Inc. ("VIS") 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 .NET 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 .NET 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. "Registry TLD" means the .NET TLD.
1.10. "Supported Protocol" means Verisign's implementation of EPP, or any
successor protocols, supported by the System.
1.11.     The "System" refers to the multiple registrar system operated by
Verisign for registration of Registered Names in the Registry TLD.
1.12. 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 by technical specifications of the System that are
made available to Registrar from time to time. 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 as Registry a non-exclusive,
royalty-free, nontransferable worldwide limited license to the data elements
consisting of the Registered Name, the IP addresses of nameservers, the identity
of the registering registrar, and other data required or permitted by technical
specifications of the Registry System as made available to Registrar by Verisign
from time to time, for propagation of and the provision of authorized access to
the TLD zone files or as otherwise required or permitted by Verisign's Registry
Agreement with ICANN concerning the operation of the Registry TLD, as may be
amended from time to time.
2.7.    Registrar's Registration Agreement and Domain Name Dispute Policy.
Registrar shall have in effect an electronic or paper registration agreement
with the 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. In its registration agreement with each Registered Name Holder, Registrar
shall require such Registered Name Holder to:
(a)
acknowledge and agree that Verisign reserves the right to deny, cancel 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, or (3) for the non-payment of fees to Verisign;
and

(b)
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. 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 Registry 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.
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.
Upon prior written notification to Registrar, Verisign may require other
industry standard security provisions, practices or technology to ensure that
the Registry 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 registrants 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 an interactive
web page and a port 43 Whois 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 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
nonarbitrary 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.
2.15.     ICANN Requirements. Verisign's obligations hereunder are subject to
modification at any time as the result of ICANN-mandated requirements and

--------------------------------------------------------------------------------

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 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 or any ICANN-Accredited Registrar, except as reasonably
necessary to register domain names or modify existing registrations.
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
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 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 ICANN 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 ICANN, 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(a)(6); and (iii)
Registrar's payment obligations as set forth in Section 5 with respect to fees
incurred during the term of this Agreement. Neither Party shall be liable to the
other for damages of any sort resulting solely from terminating this Agreement
in accordance with its terms but each Party shall be liable for any damage
arising from any breach by it 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, 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:
Vice President, VNDS LLC c/o VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Telephone: +1 703 948 3200
Facsimile: +1 703 948 3977
E-Mail:
with copies to:
VeriSign, Inc.
12061 Bluemont Way

--------------------------------------------------------------------------------

Reston, VA 20190
Telephone: +1 703 948 3200
Facsimile: +1 703 948 3977
E-Mail: cao@verisign-grs.com
- and -
General Counsel
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Telephone: +1 703 948 3200
Facsimile: +1 703 450 7492
E-Mail: legal-east@verisign.com
if to VNDS LLC only:
Managing Director, VNDS LLC c/o
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Telephone: +1 703 948 3200
Facsimile; +1 703 948 3977
E-Mail: TBP
with copies to:
(1) VeriSign, Inc.; and
(2) General Counsel, VeriSign, Inc.
(addresses above)
If to VIS only:
Managing Director, VIS c/o
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Telephone: +1 703 948 3200
Facsimile; +1 703 948 3977
E-Mail: TBP
with copies to:
(1) VeriSign, Inc.; and
(2) General Counsel, VeriSign, Inc.
(addresses above)

--------------------------------------------------------------------------------

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 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 the 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 lnformation; 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 Iaw,
regulation or court order to disclose any of Disclosing Party's Confidential
lnformation, 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. 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.
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 an accreditation agreement dated after May 21, 2009 (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 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 EPP, APIs OR
SOFTWARE WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF THE EPP,
APIs OR SOFTWARE WILL BE UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE
EPP, APIs OR SOFTWARE WILL BE CORRECTED. FURTHERMORE, VERISIGN DOES NOT WARRANT
NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE EPP, APIs,
SOFTWARE OR RELATED DOCUMENTATION IN TERMS OF THEIR CORRECTNESS, ACCURACY,
RELIABILITY, OR OTHERWISE. SHOULD THE 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
Registration Fees
1.
Domain-Name Initial Registration Fee

Registrar agrees to pay US $5.11 plus a US $0.75 ICANN fee per annual increment
of an initial domain name registration, or such other amount as may be
established in accordance with Section 5.1(b) above.
2.
Domain-Name Renewal Fee

Registrar agrees to pay US $5.11 plus a US $0.75 ICANN fee per annual increment
of a domain name registration renewal, or such other amount as may be
established in accordance with Section 5.1(b) above.
3.
Domain Name Transfer

Registrar agrees to pay US $5.11 plus a US $0.75 ICANN fee per domain name that
is transferred to Registrar from another ICANN-Accredited Registrar, or such
other amount as may be established in accordance with 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
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 Section 5.1(b) above.

--------------------------------------------------------------------------------

Exhibit B
Service Level Agreement (Appendix 10)
Appendix 10 to the .net Registry Agreement, as may be amended from time to time.

--------------------------------------------------------------------------------

NET Registry Agreement Appendix 9
Approved Services
(1 July 2017)

The Registry Agreement specifies a "Process for Consideration of Proposed
Registry Services." The following services are specifically identified as having
been approved by ICANN prior to the effective date of the Registry Agreement. As
such, notwithstanding any other provisions of the Registry Agreement, VeriSign
shall be free to deploy the following services:
•
ConsoliDate, in accordance with VeriSign's Registrar Reference Manual

•
Internationalized Domain Names, in accordance with the Letter from Rusty Lewis
to Paul Twomey dated 13 October 2003;

•
Redemption Grace Period, in accordance with VeriSign's Registrar Reference
Manual;

•
Restore, which allows use of the EPP Update command to retrieve a previously
deleted domain name registration during the Redemption Grace Period (approved by
ICANN in accordance with Verisign’s Registrar Reference Manual);

•
Wait Listing Service, in accordance with the letter from John O. Jeffrey to
Russell Lewis dated 26 January 2004;

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

--------------------------------------------------------------------------------

.NET Registry Agreement Appendix 10
Service Level Agreement (SLA)
(1 July 2017)
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.

--------------------------------------------------------------------------------

TABLE SLA Credits
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 .net 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
Registrars net new .net domain name registrations during the applicable Monthly
Timeframe divided by the net amount of new .net 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 Specifications
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 .net registrations over the previous three (3)
months (NRAvg) times the .net wholesale fee divided by the number of minutes per
day (1,440 minutes).
Active ICANN-Accredited Registrar would be credited:
(.net 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
Registrars net new .net domain name registrations during the applicable Monthly
Timeframe divided by the net amount of net new .net 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 .net domain name registrations during the applicable Monthly
Timeframe divided by the net amount of new .net 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 .net domain name registrations
during the applicable Monthly Timeframe divided by the net

--------------------------------------------------------------------------------

amount of new .net 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 .net 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 an 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 - <6 hours
≥6 hours
SLA Credit
ADM*PDO*$.25
ADM*PDO*$.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 (3)
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 .net 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 .net 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 Registrar 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.12, 5.4, or 6.3, 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.