THIRD AMENDMENT TO THE .COM REGISTRY AGREEMENT
This THIRD AMENDMENT TO THE .COM REGISTRY AGREEMENT (“Amendment 3”) is dated as
of March 27, 2020 (the “Amendment 3 Effective Date”) and is entered into by and
between the INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS, a California
non-profit public benefit corporation (“ICANN”) and VERISIGN, INC., a Delaware
corporation (“Verisign”), and amends the parties’ executed .com Registry
Agreement effective as of December 1, 2012, as amended by the First Amendment to
the .com Registry Agreement dated October 20, 2016 (“First Amendment”), and the
Second Amendment to the .com Registry Agreement dated March 27, 2019
(collectively the “Agreement”). Capitalized terms used herein shall have the
meanings assigned to them in the Agreement. ICANN and Verisign may be referred
to individually as a “Party” and collectively as the “Parties.”

WHEREAS, the Parties agreed in the First Amendment to cooperate and negotiate in
good faith to amend the terms of the Agreement (i) “to preserve and enhance the
security and stability of the Internet or the TLD” and (ii) “as may be necessary
for consistency with changes to, or termination or expiration of, the
Cooperative Agreement” between Verisign and the Department of Commerce;

WHEREAS, Verisign and the Department of Commerce entered into Amendment 35 to
the Cooperative Agreement on October 26, 2018 following the Department’s
determination that it was in the public interest to extend the term of the
Cooperative Agreement (“Cooperative Agreement”) on such terms;

WHEREAS, the Parties agree that this Amendment 3, together with the accompanying
Letter of Intent dated March 27, 2020, satisfy each Party’s obligations under
Section 2 (Future Amendments) of the First Amendment; and

WHEREAS, Verisign and ICANN desire to amend the Agreement as set forth herein.

NOW, THEREFORE, in consideration of the promises, mutual covenants and
agreements in this Amendment 3, and other good and valuable consideration the
receipt and sufficiency of which is hereby acknowledged, the Parties agree as
follows:

1.
Beginning on the Amendment 3 Effective Date, the Parties agree to work together
in good faith with the escrow provider to enter into an escrow agreement
substantially in the form of Appendix 2A (Escrow Agreement) (Template Format)
attached hereto and incorporated herein by this reference, which shall be
effective upon execution by all parties thereto, which date shall be no earlier
than 120 calendar days from the Amendment 3 Effective Date (such date of
execution, the “Updated Data Escrow Effective Date”). Verisign shall promptly
(and in any event within 15 days following the Amendment 3 Effective Date)
initiate negotiations with the escrow provider with respect to the escrow
agreement. The Parties shall use their respective best efforts to ensure that an
escrow agreement substantially in the form of Appendix 2A (Escrow Agreement)
(Template Format) is effective on the date that is 120 calendar days from the
Amendment 3 Effective Date.

2.
The Parties agree that, effective on the Updated Data Escrow Effective Date,
Section 3.1(c)(i) (Data Escrow) of the Agreement shall be deleted and replaced
in its entirety as follows:

“3.1(c)(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

1

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

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) any
domain name registrant data collected by the Registry Operator from registrars
as part of or following registration of a domain name.  The escrow agent or
mirror-site manager, and the obligations thereof, shall be mutually agreed upon
by ICANN and Registry Operator on commercially reasonable standards that are
technically and practically sufficient to allow a successor registry operator to
assume management of the TLD.”

3.
The Parties agree that, effective as of the Updated Data Escrow Effective Date,
(i) Appendix 1 (Data Escrow Specification) shall be deleted in its entirety and
replaced by Appendix 1A (Data Escrow Specification) attached hereto and
incorporated herein by this reference, (ii) Appendix 2 (Escrow Agreement) shall
be deleted in its entirety and replaced with Appendix 2A (Escrow Agreement)
(Template Format) attached hereto and incorporated herein by this reference, and
(iii) all references in the Agreement to Appendix 1 (Data Escrow Specification)
and Appendix 2 (Escrow Agreement) shall refer to Appendix 1A (Data Escrow
Specification) and Appendix 2A (Escrow Agreement) (Template Format),
respectively.

4.
The Parties agree that, effective as of 120 calendar days from the Amendment 3
Effective Date (the “Updated Bulk Zone File and Whois Service Effective Date”),
Section 3.1(c)(iii) (Bulk Zone File Access) shall be deleted and replaced in its
entirety as follows:

“3.1(c)(iii) Bulk Zone File Access. Registry Operator will make available bulk
access to zone files to third parties and ICANN in accordance with the terms of
Appendix 3A (Zone File Access), attached hereto and incorporated herein by this
reference.”

5.
The Parties agree that, effective as of the Updated Bulk Zone File and Whois
Service Effective Date, Appendix 3 (Zone File Access Agreement) shall be deleted
and replaced in its entirety with Appendix 3A (Zone File Access), in the form
attached hereto and incorporated herein by this reference, and all references in
the Agreement to Appendix 3 (Zone File Access Agreement) shall refer to Appendix
3A (Zone File Access).

6.
The Parties agree to delete Section 3.1(c)(iv) (Monthly Reporting) of the
Agreement and replace it in its entirety as follows:

“3.1(c)(iv) Monthly Reporting. Within 20 calendar days following the end of each
calendar month, Registry Operator shall prepare and deliver to ICANN reports
providing such data and, in the format specified in Appendix 4 (Registry
Operator’s Monthly Report). Notwithstanding the foregoing, beginning on June 20,
2020, Appendix 4 (Registry Operator’s Monthly Report) shall be deleted in its
entirety and replaced with Appendix 4A (Format and Content for Registry Operator
Monthly Reporting), attached hereto and incorporated herein by this reference,
and no later than the 20th calendar day of each calendar month thereafter,
Registry Operator shall prepare and deliver to ICANN reports providing such data
and in the format set forth in Appendix 4A (Format and Content for Registry
Operator Monthly Reporting).”

2

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

7.
The Parties agree that, effective as of June 20, 2020, Appendix 4 (Registry
Operator’s Monthly Report) shall be deleted and replaced in its entirety with
Appendix 4A (Format and Content for Registry Operator Monthly Reporting), in the
form attached hereto and incorporated herein by this reference, and that all
references in the Agreement to Appendix 4 (Registry Operator’s Monthly Report)
shall refer to Appendix 4A (Format and Content for Registry Operator Monthly
Reporting).

8.
The Parties agree that effective on the Updated Bulk Zone File and Whois Service
Effective Date, Section 3.1(c)(v) (Whois Service) of the Agreement shall be
deleted and replaced in its entirety as follows:

“3.1(c)(v) Registration Data Publication Services. Registry Operator shall
provide the registration data as set forth in Appendix 5A (Registration Data
Publication Services Specification) relevant to the type of top level domain
operated (e.g. “thick” or “thin” registry model). As of the Updated Bulk Zone
File and Whois Service Effective Date, the TLD is a “thin” registry model.”

9.
The Parties agree that, effective as of the Updated Bulk Zone File and Whois
Service Effective Date Appendix 5 (Whois Specifications) shall be deleted and
replaced in its entirety with Appendix 5A (Registration Data Publication
Services Specification), in the form attached hereto and incorporated herein by
this reference, and that all references in the Agreement to Appendix 5 (Whois
Specifications) will be replaced with Appendix 5A (Registration Data Publication
Services Specification).

10.
The Parties agree to add the following new Section 3.1(c)(vi) (Registration Data
Access Protocol) to the Agreement:

“3.1(c)(vi) Registration Data Access Protocol.

(A)
Within ten calendar days following the date ICANN provides notice to registry
operators under registry agreements that are the same or substantially similar
to the “Base Registry Agreement” (defined as the registry agreement set forth at
https://www.icann.org/resources/pages/registries/registries-agreements-en, as
may be amended from time to time) setting forth the effective date of an
amendment (the “RDAP Global Amendment”) to such registry agreements implementing
RDAP (the “Global Amendment Notice Date”), either party may send the other
written notice to initiate good faith negotiations to revise the terms of
Appendix 5B (and other terms of the Agreement solely as are necessary to
incorporate the terms set forth in the RDAP Global Amendment), including adding
new terms (as appropriate), related to RDDS (as defined in Appendix 5A), the
RDAP Service (as defined in Appendix 5B) and/or sunsetting of the Whois Service
(“RDAP Negotiation Request”). Upon such RDAP Negotiation Request, the parties
agree to negotiate in good faith to revise Appendix 5B, provided (i) one or more
terms set forth in the RDAP Global Amendment differ from those set forth in
Appendix 5B or other provisions of the Agreement; (ii) the terms requested to be
negotiated do not remove or lessen protections set forth in Section 1.7, Section
1.8 and Sections 2.3 through Section 2.9 of Appendix 5B, provided, however, the
Parties agree that if there is a fundamental change to the definition of RDAP
Service, as set forth in Section 1.3 of Appendix 5B (provided that a change to
the RDAP Response Profile as referenced in Appendix 5B, Section 1.3 will not be

3

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

considered a fundamental change for purposes of this subsection), then the
Parties will extend the timeframe set forth in the definition of “Ramp-up
Period” in Section 2.4 of Appendix 5B by 90 days, and extend the timeframe set
forth in Section 2.3(i) of Appendix 5B by six months; and (iii) the terms are
reasonably applicable to the TLD. In addition, except to the extent in the
reasonable judgment of Registry Operator, the implementation of any such terms
could jeopardize the security and stability of the TLD, the parties agree that
the terms set forth in the RDAP Global Amendment related to RDDS (as defined in
Appendix 5A), the RDAP Service (as defined in Appendix 5B) and/or sunsetting of
the Whois Service shall be incorporated into Appendix 5B (and other terms of the
Agreement solely as are necessary to incorporate such terms), in the form and
substance such provisions are set forth in the RDAP Global Amendment.
(B)
In the event neither party provides the other with an RDAP Negotiation Request
meeting the requirements and timeframe set forth in Section 3.1(c)(vi)(A) above,
Appendix 5B shall be effective upon the latter of: (i) the effective date of the
RDAP Global Amendment; or (ii) the 45th calendar day following ICANN’s approval
of a revised .com Registry-Registrar Agreement, if deemed reasonably necessary
by Registry Operator in order to implement the terms of Appendix 5B. In the
event Registry Operator deems that a revised .com Registry-Registrar Agreement
is reasonably necessary, Registry Operator shall use commercially reasonable
efforts to promptly (and in no event later than fifteen calendar days following
the Global Amendment Notice Date) submit a revised .com Registry-Registrar
Agreement for ICANN’s approval (and subsequently notice registrars), provided
that all such revisions shall be limited to those revisions necessary to
implement or to account for the terms of Appendix 5B, unless otherwise agreed by
the parties.

(C)
In the event either party provides the other with an RDAP Negotiation Request,
the parties will negotiate in good faith for a period of sixty calendar days,
unless otherwise extended by mutual agreement of the parties (“Negotiation
Period”). If the parties do not reach an agreement during the Negotiation Period
on revised terms as described in Section 3.1(c)(vi)(A), Appendix 5B shall be
effective upon the latter of: (i) thirty calendar days following the conclusion
of the Negotiation Period; (ii) the effective date the RDAP Global Amendment; or
(iii) the 45th calendar day following ICANN’s approval of a revised .com
Registry-Registrar Agreement, if deemed reasonably necessary by Registry
Operator in order to implement the terms of Appendix 5B. In the event Registry
Operator deems that a revised .com Registry-Registrar Agreement is reasonably
necessary, Registry Operator shall use commercially reasonable efforts to
promptly (and in no event later than twenty-one calendar days following the
conclusion of the Negotiation Period) submit a revised .com Registry-Registrar
Agreement for ICANN’s approval (and subsequently notice registrars), provided
that all such revisions shall be limited to those revisions necessary to
implement or to account for the terms of Appendix 5B, unless otherwise agreed by
the parties. In the event the parties agree upon revised terms for Appendix 5B
and the Agreement pursuant to Section 3.1(c)(vi)(A) above, such agreement will
include the date the terms will be effective.

4

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

(D)
ICANN agrees not to unreasonably withhold approval of a request by Registry
Operator to revise the .com Registry-Registrar Agreement. The parties agree that
the date the terms of Appendix 5B first apply to Registry Operator (as may be
amended by the mutual agreement of the parties), shall be referred to as the
“Appendix 5B Effective Date.”

11.
The Parties hereby agree that on the RRA Effective Date (as defined in Section
13 of this Amendment 3), Appendix 8 (.com Registry-Registrar Agreement) shall be
deleted and replaced in its entirety with Appendix 8A (.com Registry-Registrar
Agreement) in the form attached hereto and incorporated herein by this reference
(“.com RRA”) and all references to Appendix 8 (.com Registry-Registrar
Agreement) will be replaced with Appendix 8A (.com Registry-Registrar
Agreement).

12.
The Parties agree to delete the first bullet in Appendix 9 of the Agreement and
replace it with the following:

“● Consolidate/Sync Service, in accordance with Registry Operator’s Registrar
Reference Manual;”

13.
The Parties agree to add the following new Section 3.1(c)(vii) (Public Interest
Commitments) to the Agreement:

“3.1(c)(vii) Public Interest Commitments. Registry Operator shall comply with
the public interest commitments set forth in Appendix 11 (Public Interest
Commitments) attached hereto and incorporated by this reference (“Appendix 11”)
beginning on the 45th day following ICANN’s approval of the .com RRA attached
hereto as Appendix 8A (the “RRA Effective Date”).”

14.
The Parties agree to add Appendix 11 (Public Interest Commitments) to the
Agreement.

15.
The Parties hereby agree that Section 7.1(c) of the Agreement (Restrictions on
Acquisition of Ownership or Controlling Interest in Registrar) shall be deleted
and replaced as follows:

“7.1(c) Restrictions on Acquisition of Ownership or Controlling Interest in
Registrar. Registry Operator shall not acquire, directly or indirectly, control
of, or a greater than fifteen percent ownership interest in, any
ICANN-accredited registrar for the TLD.”

16.
The Parties agree to add the following to the end of Section 7.2(a) (Registry
Level Fees) of the Agreement:

“For each domain name registration in the TLD for which a registrar extends the
registration term pursuant to the Registry Operator’s Consolidate/Sync Service
(“Sync Service”) (referenced in Appendix 9 (Approved Services)) on or after May
1, 2020, Registry Operator shall pay ICANN an additional fee, prorated from the
amount of US$0.25, based on the number of days the domain name registration is
extended past its expiry date through the Sync Service (“Sync Transaction Fee”).
Registry Operator shall pay ICANN the Sync Transaction Fee by the 20th calendar
day following the end of the calendar quarter in which the Sync Services
occurred (i.e., April 20, July 20, October 20 and January 20). For the avoidance
of doubt, the Parties agree that the Sync Transaction Fee will not be applied
retroactively, and the calculation for payment to ICANN shall begin on May 1,
2020.”
     
17.
The Parties hereby agree that Section 7.3(d) of the Agreement (Maximum Price)
shall be deleted and replaced as follows:

5

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

“(d) Maximum Price. The Maximum Price for Registry Services subject to this
Section 7.3 shall be as follows:
(i) Subject to increase pursuant to Section 7.3(d)(ii) and Section 7.3(d)(iii),
the Maximum Price for Registry Services shall be US $7.85;
(ii) beginning on October 26, 2018, Registry Operator shall be entitled to
increase the Maximum Price by the smaller of (A) the Maximum Price for the
preceding Pricing Year (as defined in section (iii) below), multiplied by 1.07,
or (B) the highest price charged by Registry Operator for Registry Services
during the preceding Pricing Year, multiplied by 1.07, and in the case of (A) or
(B), in each Pricing Year of the final four Pricing Years of every six year
period, with the first six year period beginning on October 26, 2018; and

(iii) beginning on October 26, 2018, Registry Operator shall be entitled to
increase the Maximum Price by an amount sufficient to cover any additional
incremental costs incurred, or to be incurred, by Registry Operator due to the
imposition of any new Consensus Policy or documented extraordinary expense
resulting from an attack or threat of attack on the Security or Stability of the
DNS (“Consensus Policy or Documented Extraordinary Expense”) in each Pricing
Year by an amount not to exceed the smaller of (A) the Maximum Price for the
preceding Pricing Year, multiplied by 1.07, or (B) the highest price charged by
Registry Operator for Registry Services during the preceding Pricing Year,
multiplied by 1.07, provided that, Registry Operator may only increase the
Maximum Price for a Consensus Policy or Documented Extraordinary Expense
pursuant to this Section 7.3(d)(iii) in a Pricing Year where Registry Operator
has not, and will not, increase the Maximum Price for Registry Services pursuant
to Section 7.3(d)(ii) above. For purposes of Section 7.3, “Pricing Year” shall
mean the period from October 26 to October 25.

18.
Agreement; No Other Amendment; Reaffirmation. Except as amended by this
Amendment 3, the Agreement shall remain in full force and effect according to
its terms and shall be read and construed as if the terms of this Amendment 3
were included therein. The Parties acknowledge and agree that each shall be
bound and obligated to perform all of its respective obligations under the
Agreement as amended by this Amendment 3, and that all references in such
document to the Agreement shall mean and include the Agreement as amended
hereby.

19.
Incorporation by Reference. This Amendment 3 incorporates by reference the
provisions set forth in Section 8.6 (Amendments and Waivers), Section 8.7 (No
Third-Party Beneficiaries), Section 8.8 (Notices, Designations and
Specifications), Section 8.9 (Language), Section 8.10 (Counterparts) and Section
8.11 (Entire Agreement), as if fully set forth herein.

6

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

IN WITNESS WHEREOF, ICANN and Verisign have caused this Amendment 3 to be
executed and delivered by their duly authorized officers as of the Amendment 3
Effective Date.

INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS

By: /s/ Göran Marby
Name: Göran Marby
Title: President and Chief Executive Officer

VERISIGN, INC.

By: /s/ D. James Bidzos
Name: D. James Bidzos
Title: President and Chief Executive Officer

7

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

. com Registry Agreement Appendix 1A
Data Escrow Specification
(Effective as of the Updated Data Escrow Effective Date)

Registry Operator will engage an independent entity to act as data escrow agent
(the “Escrow Agent”) for the provision of data escrow services related to the
Agreement pursuant to an agreement substantially in the form of Appendix 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.

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
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/, see Section 9,
reference 1 of this Appendix and
https://datatracker.ietf.org/doc/draft-ietf-regext-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

8

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

version of the DNDE Specification available as of the Updated Data Escrow
Effective Date.  Registry Operator may at its election use newer versions of the
DNDE Specification after the Updated Data Escrow 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

9

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

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”: and

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

6.        Distribution of Public Keys.  Each of Registry Operator and Escrow
Agent will distribute its public key to the other party (Registry Operator or
Escrow Agent, as the case may be) via email to an email address to be
specified.  Each party will confirm receipt of the other party’s public key with
a reply email, and the distributing party will subsequently reconfirm the
authenticity of the key transmitted via offline methods, like in person meeting,
telephone, etc.  In this way, public key transmission is authenticated to a user
able to send and receive mail via a mail server operated by the distributing
party.  Escrow Agent, Registry Operator and ICANN will exchange public keys by
the same procedure.
7.        Notification of Deposits.  Along with the delivery of each Deposit,
Registry Operator will deliver to Escrow Agent and to ICANN (using the API
described in draft-lozano-icann-registry-interfaces, see Section 9, reference 5
of this Appendix (the “Interface Specification”)) a written statement from
Registry Operator (which may be by authenticated e-mail) that includes a copy of
the report generated upon creation of the Deposit and states that the Deposit
has been inspected by Registry Operator and is complete and accurate. The
preparation and submission of this statement must be performed by Registry
Operator or its designee, provided that such designee may not be the Escrow
Agent or any of Escrow Agent’s affiliates. Registry Operator will include the
Deposit’s “id” and “resend” attributes in its statement.  The attributes are
explained in Section 9, reference 1 of this Appendix.

10

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

If not already an RFC, Registry Operator will use the most recent draft version
of the Interface Specification at the Updated Data Escrow Effective Date. 
Registry Operator may at its election use newer versions of the Interface
Specification after the Updated Data Escrow 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),
https://datatracker.ietf.org/doc/draft-ietf-regext-data-escrow/

2)
Domain Name Registration Data (DNRD) Objects Mapping,
https://datatracker.ietf.org/doc/draft-ietf-regext-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,
https://tools.ietf.org/html/draft-lozano-icann-registry-interfaces

11

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

.com Registry Agreement Appendix 2A
Escrow Agreement (Template Format)
This Escrow Agreement ("Escrow Agreement") is made as [ ], 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 .com 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 the
“internet draft” of the Registry Interfaces Specification located at
https://tools.ietf.org/html/draft-lozano-icann-registry-interfaces as of the
Updated Data Escrow Effective Date (as defined in the Registry Agreement), that
it has received from Registry Operator such Deposit. In

12

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

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.

13

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

(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

14

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

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

15

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

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.com
9. Ownership of Deposits. The parties recognize and acknowledge that ownership
of the Deposits during the effective term of this Escrow Agreement shall remain
with Registry Operator at all times.
10. Retention and Confidentiality.
(a) Retention. Escrow Agent shall hold and maintain the Deposits 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.

16

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

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

17

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

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

18

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

E-mail: 
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

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

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

19

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

.com Registry Agreement Appendix 3A
Zone File Access
(Effective as of the Updated Bulk Zone File and Whois Service 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.

20

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

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.

21

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

1.7 No Fee for Access. Registry Operator will provide, and CZDA Provider will
facilitate, access to the zone file to user at no cost.
2. Co‐operation
2.1 Assistance. Registry Operator will co-operate and provide reasonable
assistance to ICANN and the CZDA Provider to facilitate and maintain the
efficient access of zone file data by permitted users as contemplated under this
Appendix.
2.2 ICANN Access. Registry Operator shall provide bulk access to the zone files
for the TLD to ICANN or its designee on a continuous basis in the manner ICANN
may reasonably specify from time to time. Access will be provided at least
daily. Zone files will include SRS data committed as close as possible to
00:00:00 UTC.

22

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

.com Registry Agreement Appendix 4A
Format and Content for Registry Operator Monthly Reporting
(Effective as of June 20, 2020)

Registry Operator shall provide the following monthly reports, each as described
in greater detail below, for the TLD: (1) the Service Level Agreement
Performance Report; (2) the Per-Registrar Transactions Report; and (3) the
Registry Functions Activity Report. The Service Level Agreement Performance
Reports shall be submitted to ICANN via email to <registry-reports@icann.org>.
The Per-Registrar Transactions Reports and the Registry Functions Activity
Reports shall be submitted to ICANN using the API described in
draft-lozano-icann-registry-interfaces, see
https://tools.ietf.org/html/draft-lozano-icann-registry-interfaces (the
“Registry Interfaces Specification”). If not already an RFC, Registry Operator
will use the most recent draft version of the Registry Interfaces Specification
available as of June 20, 2020. Registry Operator may at its election use newer
versions of the Registry Interfaces Specification after June 20, 2020. Once the
Registry Interfaces Specification is published as an RFC, Registry Operator will
implement the RFC version no later than one hundred eighty (180) calendar days
after it is published.
ICANN may request in the future that the reports be delivered by other means and
using other formats. For each of the reports, ICANN will use reasonable
commercial efforts to preserve the confidentiality of the information reported
until three (3) months after the end of the month to which the reports relate.
Unless set forth in this Appendix 4A, any reference to a specific time refers to
Coordinated Universal Time (UTC). Monthly reports shall consist of data that
reflects the state of the registry at the end of the month (UTC).

1.
Service Level Agreement Performance Report. This report shall compare the
Service Level Agreement requirements with actual performance measures for the
reporting month.

2.
Per-Registrar Transactions Report. This report shall be compiled in a comma
separated-value formatted file as specified in RFC 4180. The file shall be named
“net-transactions-yyyymm.csv.” The file shall contain the following fields per
registrar:

Field #
Field name
Description
1
registrar-name
Registrar’s full corporate name as registered with IANA
2
iana-id
For cases where the registry operator acts as registrar (i.e., without the use
of an ICANN accredited registrar) either 9998 or 9999 should be used depending
on registration type, otherwise the sponsoring Registrar IANA id should be used
as specified in http://www.iana.org/assignments/registrar-ids
3
total-domains
total domain names under sponsorship in any EPP status but pendingCreate that
have not been purged

23

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

4
total-nameservers
total name servers (either host objects or name server hosts as domain name
attributes) associated with domain names registered for the TLD in any EPP
status but pendingCreate that have not been purged
5
net-adds-1-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of one (1) year (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
6
net-adds-2-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of two(2) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
7
net-adds-3-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of three (3) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
8
net-adds-4-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of four (4) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
9
net-adds-5-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of five (5) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
10
net-adds-6-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of six (6) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
11
net-adds-7-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of seven (7) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
12
net-adds-8-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of eight (8) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
13
net-adds-9-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of nine (9) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.
14
net-adds-10-yr
number of domains successfully registered (i.e., not in EPP pendingCreate
status) with an initial term of ten (10) years (and not deleted within the add
grace period). A transaction must be reported in the month the add grace period
ends.

24

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

15
net-renews-1-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of one (1) year
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
16
net-renews-2-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of two (2) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
17
net-renews-3-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of three (3) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
18
net-renews-4-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of four (4) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
19
net-renews-5-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of five (5) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
20
net-renews-6-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of six (6) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
21
net-renews-7-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of seven (7) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
22
net-renews-8-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of eight (8) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
23
net-renews-9-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of nine (9) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.

25

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

24
net-renews-10-yr
number of domains successfully renewed (i.e., not in EPP pendingRenew status)
either automatically or by command with a new renewal period of ten (10) years
(and not deleted within the renew or auto-renew grace period). A transaction
must be reported in the month the renew or auto-renew grace period ends.
25
transfer-gaining-successful
number of domain transfers initiated by this registrar that were successfully
completed (either explicitly or automatically approved) and not deleted within
the transfer grace period. A transaction must be reported in the month the
transfer grace period ends.
26
transfer-gaining-nacked
number of domain transfers initiated by this registrar that were rejected (e.g.,
EPP transfer op="reject") by the other registrar
27
transfer-losing-successful
number of domain transfers initiated by another registrar that were successfully
completed (either explicitly or automatically approved)
28
transfer-losing-nacked
number of domain transfers initiated by another registrar that this registrar
rejected (e.g., EPP transfer op="reject")
29
transfer-disputed-won
number of transfer disputes in which this registrar prevailed (reported in the
month where the determination happened)
30
transfer-disputed-lost
number of transfer disputes this registrar lost (reported in the month where the
determination happened)
31
transfer-disputed-nodecision
number of transfer disputes involving this registrar with a split or no decision
(reported in the month where the determination happened)
32
deleted-domains-grace
domains deleted within the add grace period (does not include names deleted
while in EPP pendingCreate status). A deletion must be reported in the month the
name is purged.
33
deleted-domains-nograce
domains deleted outside the add grace period (does not include names deleted
while in EPP pendingCreate status). A deletion must be reported in the month the
name is purged.
34
restored-domains
domain names restored during reporting period
35
restored-noreport
total number of restored names for which a restore report is required by the
registry, but the registrar failed to submit it
36
agp-exemption-requests
total number of AGP (add grace period) exemption requests
37
agp-exemptions-granted
total number of AGP (add grace period) exemption requests granted
38
agp-exempted-domains
total number of names affected by granted AGP (add grace period) exemption
requests
39
attempted-adds
number of attempted (both successful and failed) domain name create commands
40
consolidate-transaction-days
total number of days added to the expiration date of all domain names via
consolidate/synch transactions. The number of days of a consolidate/synch
transaction must be reported here in the month the transaction took place.

26

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

41
consolidate-transactions
total number of consolidate/synch transactions. A transaction must be reported
in the month the transaction took place.

The first line shall include the field names exactly as described in the table
above as a “header line” as described in section 2 of RFC 4180. The last line of
each report shall include totals for each column across all registrars; the
first field of this line shall read “Totals” while the second field shall be
left empty in that line. No other lines besides the ones described above shall
be included. Line breaks shall be <U+000D, U+000A> as described in RFC 4180.
3.
Registry Functions Activity Report. This report shall be compiled in a comma
separated-value formatted file as specified in RFC 4180. The file shall be named
“net-activity-yyyymm.csv.” The file shall contain the following fields:

Field #
Field Name
Description
1
operational-registrars
number of operational registrars in the production system at the end of the
reporting period
2
zfa-passwords
number of active zone file access passwords at the end of the reporting period;
"CZDS" may be used instead of the number of active zone file access passwords,
if the Centralized Zone Data Service (CZDS) is used to provide the zone file to
the end user
3
whois-43-queries
number of WHOIS (port-43) queries responded during the reporting period
4
web-whois-queries
number of Web-based Whois queries responded during the reporting period, not
including searchable Whois
5
searchable-whois-queries
number of searchable Whois queries responded during the reporting period, if
offered
6
dns-udp-queries-received
number of DNS queries received over UDP transport during the reporting period
7
dns-udp-queries-responded
number of DNS queries received over UDP transport that were responded during the
reporting period
8
dns-tcp-queries-received
number of DNS queries received over TCP transport during the reporting period
9
dns-tcp-queries-responded
number of DNS queries received over TCP transport that were responded during the
reporting period
10
srs-dom-check
number of SRS (EPP and any other interface) domain name “check” requests
responded during the reporting period
11
srs-dom-create
number of SRS (EPP and any other interface) domain name “create” requests
responded during the reporting period
12
srs-dom-delete
number of SRS (EPP and any other interface) domain name “delete” requests
responded during the reporting period

27

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

13
srs-dom-info
number of SRS (EPP and any other interface) domain name “info” requests
responded during the reporting period
14
srs-dom-renew
number of SRS (EPP and any other interface) domain name “renew” requests
responded during the reporting period
15
srs-dom-rgp-restore-report
number of SRS (EPP and any other interface) domain name RGP “restore” requests
delivering a restore report responded during the reporting period
16
srs-dom-rgp-restore-request
number of SRS (EPP and any other interface) domain name RGP “restore” requests
responded during the reporting period
17
srs-dom-transfer-approve
number of SRS (EPP and any other interface) domain name “transfer” requests to
approve transfers responded during the reporting period
18
srs-dom-transfer-cancel
number of SRS (EPP and any other interface) domain name “transfer” requests to
cancel transfers responded during the reporting period
19
srs-dom-transfer-query
number of SRS (EPP and any other interface) domain name “transfer” requests to
query about a transfer responded during the reporting period
20
srs-dom-transfer-reject
number of SRS (EPP and any other interface) domain name “transfer” requests to
reject transfers responded during the reporting period
21
srs-dom-transfer-request
number of SRS (EPP and any other interface) domain name “transfer” requests to
request transfers responded during the reporting period
22
srs-dom-update
number of SRS (EPP and any other interface) domain name “update” requests (not
including RGP restore requests) responded during the reporting period
23
srs-host-check
number of SRS (EPP and any other interface) host “check” requests responded
during the reporting period
24
srs-host-create
number of SRS (EPP and any other interface) host “create” requests responded
during the reporting period
25
srs-host-delete
number of SRS (EPP and any other interface) host “delete” requests responded
during the reporting period
26
srs-host-info
number of SRS (EPP and any other interface) host “info” requests responded
during the reporting period
27
srs-host-update
number of SRS (EPP and any other interface) host “update” requests responded
during the reporting period
28
srs-cont-check
number of SRS (EPP and any other interface) contact “check” requests responded
during the reporting period
29
srs-cont-create
number of SRS (EPP and any other interface) contact “create” requests responded
during the reporting period
30
srs-cont-delete
number of SRS (EPP and any other interface) contact “delete” requests responded
during the reporting period

28

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

31
srs-cont-info
number of SRS (EPP and any other interface) contact “info” requests responded
during the reporting period
32
srs-cont-transfer-approve
number of SRS (EPP and any other interface) contact “transfer” requests to
approve transfers responded during the reporting period
33
srs-cont-transfer-cancel
number of SRS (EPP and any other interface) contact “transfer” requests to
cancel transfers responded during the reporting period
34
srs-cont-transfer-query
number of SRS (EPP and any other interface) contact “transfer” requests to query
about a transfer responded during the reporting period
35
srs-cont-transfer-reject
number of SRS (EPP and any other interface) contact “transfer” requests to
reject transfers responded during the reporting period
36
srs-cont-transfer-request
number of SRS (EPP and any other interface) contact “transfer” requests to
request transfers responded during the reporting period
37
srs-cont-update
number of SRS (EPP and any other interface) contact “update” requests responded
during the reporting period
38
rdap-queries
total number of RDAP queries responded (e.g., including search queries,
redirects, positive and negative answers, rate-limited queries, authorized or
not) during the period. Notwithstanding anything to the contrary, Registry
Operator shall provide the data in this reporting line beginning in the first
report following the Appendix 5B Effective Date for which a full month of data
is available.

The first line shall include the field names exactly as described in the table
above as a “header line” as described in section 2 of RFC 4180. No other lines
besides the ones described above shall be included. Line breaks shall be
<U+000D, U+000A> as described in RFC 4180.
For gTLDs that are part of a single-instance Shared Registry System, the
Registry Functions Activity Report may include the total contact or host
transactions for all the gTLDs in the system.

29

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

.com Registry Agreement Appendix 5A
Registration Data Publication Services Specification
(Effective as of the Updated Bulk Zone File and Whois Service Effective Date)

A.
Registration Data Directory Services. Registration Data Directory Services (or
RDDS) refers to the collective of WHOIS (via port 43), WHOIS web-based directory
service(s) and Registration Data Access Protocol (“RDAP”) services, as defined
in this Appendix. Registry Operator shall offer public IPv6 and IPv4 transports
for its RDDS. Registry Operator will operate a WHOIS service available via port
43 in accordance with RFC 3912 at whois.verisign.net, and a WHOIS web-based
directory service at www.verisign.com/whois providing free public query-based
access to the elements defined in this Appendix 5A.

B.
Solely as it relates to this Appendix 5A, Registry Operator shall operate an
“RDAP service” for querying registration data using a RESTful web service and
uniform query patterns as defined in RFCs: 7480-7484, 8056, 8605.

C.
Registry Operator must implement only those sections of the Registration Data
Consistent Labeling and Display Policy
(https://www.icann.org/resources/pages/rdds-labeling-policy-2017-02-01-en) in
conjunction with this Appendix 5A that are relevant to the type of TLD operated,
e.g., “thick” or “thin” registry model (e.g. exclude information from any
contact: registrant, admin, tech, billing etc.). As of the Updated Bulk Zone
File and Whois Service Effective Date, the .com TLD is considered a “thin”
registry model.

30

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

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

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
Registry Domain ID: D1234567-TLD
Registrar WHOIS Server: whois.example.tld
Registrar URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Registrar: EXAMPLE REGISTRAR LLC
Registrar IANA ID: 5555555
Registrar Abuse Contact Email: email@registrar.tld
Registrar Abuse Contact Phone: +1.1235551234
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registry Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1

31

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

Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Registry Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Registry Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<

1.6.
Registrar Data:

1.6.1
Query format: whois “registrar Example Registrar, Inc.”

1.6.2
Response format:

Registrar: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292

32

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

Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
Email: registrar@example.tld
Registrar WHOIS Server: whois.example-registrar.tld
Registrar URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.7.
Nameserver Data:

1.7.1
Query format: whois “nameserver (nameserver name)”, or whois “nameserver (IP
Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.

1.7.2
Response format:

Server Name: NS1.EXAMPLE.TLD
IP Address: 192.0.2.123
IP Address: 2001:0DB8::1
Registrar: Example Registrar, Inc.
Registrar WHOIS Server: whois.example-registrar.tld
Registrar URL: http://www.example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.8.
The format of the following data fields: domain status, individual and
organizational names, address, street, city, state/province, postal code,
country, telephone and fax numbers (the extension will be provided as a separate
field as shown above), email addresses, date and times should conform to the
mappings specified in EPP RFCs 5730-5734 so that the display of this information
(or values return in WHOIS responses) can be uniformly processed and understood.

1.9.
Searchability. Offering searchability capabilities on the WHOIS web-based
directory services is optional but if offered by the Registry Operator it shall
comply with the specification described in this section.

1.9.1
Registry Operator will offer searchability on the WHOIS web-based directory
service.

33

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

1.9.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.9.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.9.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.9.5
Search results will include domain names matching the search criteria.

1.9.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.10.
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 the registration directory services policy and
educational materials. ICANN designates https://lookup.icann.org as such web
page and may update its designation from time to time, in which case Registry
Operator shall implement the new web page link on its primary website within
thirty (30) calendar days of ICANN’s designation and notification to the
Registry Operator.

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 the Registry Services, analyze the operational
stability of the DNS and facilitate compliance checks and audits of accredited
registrars, Registry Operator will provide ICANN on a daily basis with
up-to-date registration data as specified below. Data will include data
committed as of 00:00:00 UTC on the day previous day.
2.1.1    Contents. Registry Operator must only provide the following data for
all registered domain names: domain name, domain name repository object id
(roid), Registrar ID (IANA ID), statuses, last updated date, creation date,
expiration date, and name server names. For sponsoring registrars, Registry
Operator must only 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.

34

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

2.1.3    Access. Registry Operator will have the file(s) ready for download as
of 00:00:00 UTC for retrieval by ICANN. The file(s) will be made available for
download by SFTP, though ICANN may request other means in the future.
2.2    Exceptional Access to Thick Registration Data. This Section 2.2 shall
only apply on or after the date the TLD is operated as a “thick” registry model,
if any. In case of a registrar failure, deaccreditation, court order, etc. that
prompts the temporary or definitive transfer of its domain names to another
registrar, at the request of ICANN, Registry Operator will provide ICANN with
up-to-date data for the domain names of the losing registrar. The data will be
provided in the format specified in Appendix 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.

35

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

.com Registry Agreement Appendix 5B
Registration Data Access Protocol Service Specification
(Effective in accordance with Section 3.1(c)(vi))

1.
Scope and Definitions.

1.1.     “Appendix 5B Effective Date” is as defined in Section 3.1(c)(vi) of the
Agreement.
 
1.2    “Base Registry Agreement” is defined in Section 3.1(c)(vi) of the
Agreement.

1.3.    The “RDAP Service” is a standard for the querying of registration data
using a RESTful web service and uniform query patterns. For the purposes of this
Agreement, implementation of RDAP shall be defined by the RDAP Technical
Implementation Guide version dated February 15, 2019
https://www.icann.org/en/system/files/files/rdap-technical-implementation-guide-15feb19-en.pdf
and the RDAP Response Profile version dated February 15, 2019
https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en.pdf.
Registry Operator shall implement the RDAP Service solely in accordance with the
IETF standards documents set forth in the RDAP Technical Implementation Guide
and RDAP Response Profile versions listed above and any additional references
set forth in those documents shall be considered informational only.

1.4.    “RDAP-query RTT” means the round-trip time (“RTT”) of the sequence of
packets from the start of an RDAP testing probe’s TCP connection to its end,
including the reception of the HTTPS response for only one HTTPS request. If
implementing a multiple step process to get to the information, only the last
step shall be measured. If the RTT is 5-times or more the corresponding
SLR/performance specifications, the RTT will be considered undefined.
 
1.5.    “RDAP Availability” refers to the ability of the RDAP Service for the
TLD, to respond to queries from an Internet user with the data from the Registry
Operator System. If 51% or more of the verifiably working RDAP testing probes
see the RDAP Service as unavailable during a given time, the RDAP Service will
be considered unavailable, subject to Section 3.7 below, and as otherwise set
forth in this Agreement.
 
1.6.     “RDAP Update Time” refers to the time measured from the receipt of an
EPP confirmation to a transform command on a domain name, host or contact, up
until at least 51% of the verifiably working RDAP testing probes detect the
changes made.
 
1.7.    “RDAP Outage” means a failure to meet the same parameter of the RDAP
Service Level Requirements in Section 2.1 for two (2) consecutive months,
provided, however, no failure shall be deemed an “RDAP Outage” for the RDAP
Availability parameter unless the failure is also the result of two (2) separate
incidents for which the conclusion of the impact period for the first incident
and the commencement of the impact period for the second incident are at least
seven (7) calendar days apart.

1.8.    “SLA Credits” means the Service Level Credits set forth in the Table SLA
Credits in Section 2 of Appendix 10 (Service Level Agreement (SLA)) and in
accordance with Section 2.8 below.

36

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

 
2.
Service Level Requirements. Registry Operator shall comply with the following
performance specifications:

 
2.1. Service Level Requirements Matrix
 
 
Parameter
Service Level Requirements (SLR)/Performance Specification
 (monthly basis)
RDAP
RDAP Availability
≦ 864 min of downtime (98%)
 
RDAP query RTT unauthenticated lookups with exact match
≦ 5000 ms, for at least 95% of the queries
 
RDAP Update Time
≦ 60 min, for at least 95% of the updates

 
2.2.    Registry Operator is encouraged to do maintenance for RDAP at the times
and dates of statistically lower traffic for each parameter. However, there is
no provision for planned outages or similar periods of unavailability; any
downtime, be it for maintenance or due to system failures, will be noted simply
as downtime and counted for Service Level Requirement measurement purposes.
 
2.3.    The remedies for a failure to meet an RDAP Service Level Requirement set
forth in Section 2.1 shall be solely as set forth in this Agreement as it
pertains to the equivalent remedies for a failure to meet the corresponding
Performance Specification for the Whois service, provided, however, that (i) for
six months after the Ramp-Up Period (as defined in Section 2.4 below), a failure
of a Registry Operator to meet a service-level requirement for the RDAP Service
shall only apply if the Registry Operator has experienced an “RDAP Outage” of
the RDAP Service; and (ii) in the event of a concurrent failure of the RDAP

Service and Whois service in a given month, SLA Credits, if applicable, for
Registrars shall not exceed the total amount of SLA Credits attributable solely
to the failure of the service-level requirement for the Whois service, pursuant
to Registry Operator’s Agreement.  
 
2.4.    Ramp-Up Period. With respect to the Service Level Requirements
identified in Section 2.1, Registry Operator shall not be deemed to have
breached such Service Level Requirements due to any failure to meet those
Service Level Requirements during the first 90 days following the Appendix 5B
Effective Date (“Ramp-up Period”).

2.5.    The Parties agree that the SLA Credits are the total credits, penalties
and/or liabilities that may be assessed to Registry Operator and the sole
remedies available to registrar for Registry Operator’s failure to meet the
Service Level Requirements for the RDAP Service.

2.6.    Registry Operator will use commercially reasonable efforts to restore
the RDAP Service 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 Appendix 7 or the Service Level Requirements.

37

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

2.7.    Registry Operator shall not be liable to ICANN or registrars for any
credits or penalties, or be deemed to be in breach of any of its obligations
under the Agreement if it fails to meet a Service Level Requirement for the RDAP
Service as a result of its compliance with any Consensus Policy established
after the Amendment 3 Effective Date, to the extent and for so long as, the
failure to meet the Service Level Requirement for the RDAP Service is
unavoidable by commercially reasonable efforts due to Registry Operator's
compliance with such Consensus Policy.

2.8.    The Service Level Requirements for the RDAP Service shall be considered
“Performance Specifications” and the “RDAP Service” shall be considered a
“System Service” solely for purposes of Appendix 10 (Service Level Agreement)
(SLA)). Notwithstanding anything to the contrary in Section 4.5 of Appendix 10
(Service Level Agreement), for purposes of the RDAP Service only, Registry
Operator’s obligations regarding restoration of RDAP Service following a force
majeure event shall be as set forth in Section 2.6 of this Appendix 5B.

2.9.    In order to determine the appropriate credit level and calculation of an
SLA Credit due to a failure by the Registry Operator to meet a Service Level
Requirement, the credit level and calculation shall be based on the equivalent
reference set forth in the chart below and in accordance with this Agreement.
 
RDAP Service Level Requirement
Equivalent Reference for Purposes of Calculating the Credit Level of the SLA
Credit
RDAP Availability
Service Availability--Whois
RDAP-query RTT
Processing Time--Whois Query
RDAP Update Time
Update Frequency

3.
RDAP Measurement Parameters.

 
3.1.    RDAP test. Means one query sent to a particular “IP address” of one of
the servers of one of the RDAP Service. Queries shall be about existing objects
in the Registry Operator System and the responses shall contain the
corresponding information otherwise the query will be considered unanswered.
Queries with an RTT 5 times higher than the corresponding Service Level
Requirement will be considered as unanswered. The possible results to an RDAP
test are: a number in milliseconds corresponding to the RTT or
undefined/unanswered.
 
3.2.    Measuring RDAP parameters. Every 5 minutes, each of the RDAP testing
probes will query the DNS to obtain the IP address(es) of the RDAP Service,
select an IP address (if there is more than one), and make an “RDAP test” to
that IP address. If an “RDAP test” result is undefined/unanswered, the
corresponding RDAP Service will be considered as unavailable from that probe
until it is time to make a new test.
 
3.3.    Collating the results from RDAP probes. The minimum number of verifiably
working RDAP testing probes to consider a measurement valid is 20 at any given
measurement period, otherwise the measurements will be discarded and will be
considered ‘inconclusive’; during this situation no fault will be flagged
against the Service Level Requirements.
 

38

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

3.4.    Placement of RDAP probes. Probes for measuring RDAP parameters shall be
placed by ICANN inside the networks with the most RDAP users across the
different geographic regions; ICANN shall take care not to deploy probes behind
high propagation-delay links, such as satellite links.
 
3.5.    No interference. Registry Operator shall not interfere with measurement
probes, including any form of preferential treatment of the requests for the
monitored services. Registry Operator shall respond to the measurement tests
described in this Appendix as it would to any other request from an Internet
user for RDAP.
 
3.6.    Base URL of RDAP Service. Registry Operator shall submit the base URL of
its RDAP Service for publication in the Bootstrap Service Registry for Domain
Name Space in accordance with the RDAP Technical Implementation Guide.
 
3.7.    Right to Challenge Probes’ Measurements. In the event Registry Operator
believes that the RDAP testing probes measuring any of the RDAP parameters set
forth in Section 2.1 above have not accurately measured one or more parameters,
the Registry Operator shall have the right to challenge the RDAP testing probes’
measurements with ICANN, and, in that event, ICANN and the Registry Operator
will cooperate to address and resolve any discrepancies prior to finalization of
the measurement.

39

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

.com Registry Agreement Appendix 8A
.com Registry-Registrar Agreement
(Effective as of the RRA Effective Date)

.COM Registry-Registrar Agreement

This Registry-Registrar Agreement (the "Agreement") is entered into by and
between VeriSign, Inc., a Delaware corporation, with a place of business located
at 12061 Bluemont Way, Reston, VA 20190, and its wholly owned subsidiaries,
including VeriSign Sarl and VeriSign Naming and Directory Services LLC ("VNDS
LLC") (collectively, "Verisign"), and ____________, a ______________, with its
principal place of business located at _______("Registrar"), through their
authorized representatives, and takes effect on DAY, MONTH YEAR (the "Effective
Date"). Verisign and Registrar may be referred to individually as a "Party" and
collectively as the "Parties."
WHEREAS, multiple registrars provide Internet domain name registration services
within the .COM top-level domain wherein Verisign operates and maintains certain
TLD servers and zone files;
WHEREAS, Registrar wishes to register second-level domain names in the multiple
registrar system for the .COM TLD.
NOW, THEREFORE, for and in consideration of the mutual promises, benefits and
covenants contained herein and for other good and valuable consideration, the
receipt, adequacy and sufficiency of which are hereby acknowledged, Verisign and
Registrar, intending to be legally bound, hereby agree as follows:
1.DEFINITIONS
1.1.    "Confidential Information" means all information and materials
including, without limitation, computer software, data, information, databases,
protocols, reference implementation and documentation, and functional and
interface specifications, provided by the disclosing party to the receiving
party and marked or otherwise identified as Confidential, provided that if a
communication is oral, the Disclosing Party will notify the Receiving Party in
writing within 15 days of the disclosure.
1.2.     "DNS" refers to the Internet domain name system.
1.3.    "EPP" means the Extensible Provisioning Protocol.
1.4.    "ICANN" refers to the Internet Corporation for Assigned Names and
Numbers.
1.5.    "IP" means Internet Protocol.
1.6.    The "Licensed Product" refers to the intellectual property required to
access the Supported Protocol, and to the APIs, and software, collectively.
1.7.    "Personal Data" refers to data about any identified or identifiable
natural person.

40

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

1.8.    "Registered Name" refers to a domain name within the domain of the
Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels,
about which Verisign or an affiliate engaged in providing registry services
maintains data in a registry database, arranges for such maintenance, or derives
revenue from such maintenance. A name in a registry database may be a Registered
Name even though it does not appear in a TLD zone file (e.g., a registered but
inactive name).
1.9.    “Registered Name Holder(s)” means the holder(s) of a Registered Name.
1.10.    “Registrar Accreditation Agreement” means that certain Registrar
Accreditation Agreement between Registrar and ICANN pursuant to which ICANN has
accredited Registrar to act as a registrar for one or more TLDs.
1.11.    "Registry TLD" means the .COM TLD.
1.12.    "Supported Protocol" means Verisign's implementation of EPP, or any
successor protocols, supported by the System.
1.13.    The "System" refers to the shared registration system operated by
Verisign for registration of Registered Names in the Registry TLD.
1.14.    A "TLD" is a top-level domain of the DNS.
2.    OBLIGATIONS OF THE PARTIES
2.1.    System Operation and Access. Throughout the term of this Agreement,
Verisign shall operate the System and provide Registrar with access to the
System to transmit domain name registration information for the Registry TLD to
the System. Nothing in this Agreement entitles Registrar to enforce any
agreement between Verisign and ICANN.
2.2.    Maintenance of Registrations Sponsored by Registrar. Subject to the
provisions of this Agreement, ICANN requirements, and Verisign requirements,
including, without limitation, those authorized by ICANN, Verisign shall
maintain the registrations of Registered Names sponsored by Registrar in the
System during the term for which Registrar has paid the fees required by
Subsection 5.1.
2.3.    Distribution of EPP, APIs and Software. No later than three (3) business
days after the Effective Date of this Agreement, Verisign shall make available
to Registrar (i) full documentation of the Supported Protocol, (ii) "C" and/or
"Java" application program interfaces ("APIs") to the Supported Protocol with
documentation, and (iii) reference client software ("Software") that will allow
Registrar to develop its system to register second-level domain names through
the System for the Registry TLD. If Verisign elects to modify or upgrade the
APIs and/or Supported Protocol, Verisign shall provide updated APIs to the
Supported Protocol with documentation and updated Software to Registrar promptly
as such updates become available.
2.4.    Registrar Responsibility for Customer Support. Registrar shall provide
(i) support to accept orders for registration, cancellation, modification,
renewal, deletion or transfer of Registered Names and (ii) customer service
(including domain name record support) and billing and technical support to
Registered Name Holders. Registrar shall, consistent with ICANN policy, provide
to Registered Name Holders emergency contact or 24/7 support information for
critical situations such as domain name hijacking.

41

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

2.5.    Data Submission Requirements. As part of its registration and
sponsorship of Registered Names in the Registry TLD, Registrar shall submit
complete data as required or permitted: (a) by Verisign’s Registry Agreement
with ICANN, as may be amended from time to time; and/or (b) by technical
specifications of the System that are made available to Registrar by Verisign
from time to time (collectively the “Required Data Elements”). Registrar shall
submit any corrections or updates from a Registered Name Holder relating to the
registration information for a Registered Name to Verisign in a timely manner.
2.6.    License. Registrar grants Verisign a non-exclusive, royalty-free,
nontransferable (except to ICANN or its designee pursuant to Verisign’s Registry
Agreement with ICANN) worldwide limited license to the Required Data Elements:
(a) for use as required or permitted by technical specifications of the System
as made available to Registrar by Verisign from time to time; and/or (b) for use
and display as required or permitted by Verisign's Registry Agreement with
ICANN, as may be amended from time to time.
2.7.    Registrar's Registration Agreement and Domain Name Dispute Policy.
(a)
Registrar shall have in effect a valid and enforceable electronic or paper
registration agreement with each Registered Name Holder which may be amended
from time to time by Registrar, provided a copy is made available to Verisign.
Registrar shall provide a copy of Registrar's registration agreement upon
request for same by Verisign. Registrar shall include in its registration
agreement those terms required by this Agreement and other terms that are
consistent with Registrar's obligations to Verisign under this Agreement.
Registrar shall employ in its domain name registration business the Uniform
Domain Name Dispute Resolution Policy and the Inter-Registrar Transfer Policy,
each as adopted by the ICANN Board on 26 August 1999 and 7 November 2008 and as
each may be amended from time to time.

(b)
Registrar’s registration agreement with each Registered Name Holder shall also
include the following:

(i) a provision prohibiting the Registered Name Holder from distributing
malware, abusively operating botnets, phishing, pharming, piracy, trademark or
copyright infringement, fraudulent or deceptive practices, counterfeiting or
otherwise engaging in activity contrary to applicable law and providing
(consistent with applicable law and any related procedures) consequences for
such activities, including suspension of the registration of the Registered
Name;
(ii) a provision that requires the Registered Name Holder to acknowledge and
agree that Verisign reserves the right to deny, cancel, redirect or transfer any
registration or transaction, or place any domain name(s) on registry lock, hold
or similar status, as it deems necessary, in its unlimited and sole discretion:
(1) to comply with specifications adopted by any industry group generally
recognized as authoritative with respect to the Internet (e.g., RFCs), (2) to
correct mistakes made by Verisign or any Registrar in connection with a domain
name registration, (3) for the non-payment of fees to Verisign, (4) to protect
against imminent and substantial threats to the security and stability of the
Registry TLD, System, Verisign’s nameserver operations or the internet, (5) to
ensure compliance with applicable law, government rules or regulations, or
pursuant to any legal order or subpoena of any government, administrative or
governmental authority, or court of competent jurisdiction, and/or (6) to stop
or prevent any violations of any terms and

42

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

conditions of this Agreement, the Operational Requirements, or pursuant to
Verisign’s Registry Agreement with ICANN; and
(iii) a provision requiring the Registered Name Holder to indemnify, defend and
hold harmless Verisign and its subcontractors, and its and their directors,
officers, employees, agents, and affiliates from and against any and all claims,
damages, liabilities, costs and expenses, including reasonable legal fees and
expenses arising out of or relating to, for any reason whatsoever, the
Registered Name Holder's domain name registration. The registration agreement
shall further require that this indemnification obligation survive the
termination or expiration of the registration agreement.
2.8.     Secure Connection.
(a)
Registrar agrees to develop and employ in its domain name registration business
all necessary technology and restrictions to ensure that its connection to the
System is secure. All data exchanged between Registrar's system and the System
shall be protected to avoid unintended disclosure of information. Registrar
shall employ commercially reasonable measures to prevent its access to the
System granted hereunder from being used to (i) allow, enable, or otherwise
support the transmission by e-mail, telephone, or facsimile of mass unsolicited,
commercial advertising or solicitations to entities other than its own existing
customers; or (ii) enable high volume, automated, electronic processes that send
queries or data to the systems of Verisign, any other registry operated under an
agreement with ICANN, or any ICANN-accredited registrar, except as reasonably
necessary to register domain names or modify existing registrations in
accordance with any Operational Requirements.

(b)
Each EPP session shall be authenticated and encrypted using two-way secure
socket layer ("SSL") protocol. Registrar agrees to authenticate every EPP client
connection with the System using both an X.509 server certificate issued by a
commercial Certification Authority identified by the Registry and its Registrar
password, which it shall disclose only to its employees with a need to know.
Registrar agrees to notify Registry within four (4) hours of learning that its
Registrar password has been compromised in any way or if its server certificate
has been revoked by the issuing Certification Authority or compromised in any
way.

(c)
Upon prior written notification to Registrar, Verisign may require other
industry standard security provisions, practices or technology to ensure that
the System is secure and stable, which Verisign may adopt from time to time in
its sole and complete discretion.

2.8.1.    Handling of Personal Data.
Verisign shall notify Registrar of the purposes for which Personal Data
submitted to Verisign by Registrar is collected, the intended recipients (or
categories of recipients) of such Personal Data, and the mechanism for access to
and correction of such Personal Data. Verisign shall take reasonable steps to
protect Personal Data from loss, misuse, unauthorized disclosure, alteration or
destruction. Verisign shall not use or authorize the use of Personal Data in a
way that is incompatible with the notice provided to registrars. Verisign may
from time to time use the demographic data collected for statistical analysis,
provided that this analysis will not disclose individual Personal Data and
provided that such use is compatible with the notice provided to registrars
regarding the purpose and procedures for such use.

43

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

2.8.2.        Authorization Codes. Registrar shall not provide identical
Registrar-generated authorization <authinfo> codes for domain names registered
by different Registered Name Holders with the same Registrar. Verisign in its
sole discretion may choose to modify <authinfo> codes for a given domain and
shall notify the sponsoring registrar of such modifications via EPP compliant
mechanisms (i.e., EPP<poll> or EPP<domain:Info>). Documentation of these
mechanisms shall be made available to Registrar by Verisign. The Registrar shall
provide the Registered Name Holder with timely access to the authorization code
along with the ability to modify the authorization code. Registrar shall respond
to any inquiry by a Registered Name Holder regarding access to and/or
modification of an authorization code within five (5) calendar days.
2.9.    Domain Name Lookup Capability. Registrar agrees to employ in its domain
name registration business Verisign's registry domain name lookup capability to
determine if a requested domain name is available or currently unavailable for
registration. Registrar also agrees, at its expense, to provide a Registration
Data Directory Service providing free public query-based access to up-to-date
(i.e., updated at least daily) data concerning all active Registered Names
sponsored by Registrar for the Registry TLD. The data accessible shall consist
of elements that are designated from time to time according to an ICANN adopted
specification or policy or the Registrar Accreditation Agreement between
Registrar and ICANN.
2.10.    Transfer of Sponsorship of Registrations. Registrar agrees to implement
transfers of Registered Name registrations from another registrar to Registrar
and vice versa or from one Registered Name Holder to another pursuant to the
Inter-Registrar Transfer Policy as may be amended from time to time by ICANN
(the "Transfer Policy").
2.11.    Time. Registrar agrees that in the event of any dispute concerning the
time of the entry of a domain name registration into the registry database, the
time shown in the Verisign records shall control.
2.12.    Compliance with Operational Requirements. Registrar shall comply with
each of the following requirements, and further shall include in its
registration agreement with each Registered Name Holder, as applicable, an
obligation for such Registered Name Holder to comply with each of the following
requirements:
(a)
ICANN standards, policies, procedures, and practices for which Verisign has
monitoring responsibility in accordance with the Registry Agreement or other
arrangement with ICANN; and

(b)
Operational standards, policies, procedures, and practices for the Registry TLD
established from time to time by Verisign in a non-arbitrary manner and
applicable to all registrars ("Operational Requirements"), including affiliates
of Verisign, and consistent with Verisign's Registry Agreement with ICANN, as
applicable, upon Verisign's notification to Registrar of the establishment of
those terms and conditions.

2.13.    Resolution of Technical Problems or Breach of Agreement. Registrar
agrees to employ necessary employees, contractors, or agents with sufficient
technical training and experience to respond to and fix all technical problems
concerning the use of the Supported Protocol, the APIs and the systems of
Verisign in conjunction with Registrar's systems. Registrar agrees that in the
event of significant degradation of the System or other emergency, or upon
Registrar's violation of Operational Requirements or breach of this Agreement,
Verisign may, in its sole discretion,

44

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

temporarily suspend or restrict access to the System. Such temporary suspensions
or restrictions shall be applied in a non-arbitrary manner and shall apply
fairly to any registrar similarly situated.
2.14.    Prohibited Domain Name Registrations. In addition to complying with
ICANN standards, policies, procedures, and practices limiting domain names that
may be registered, Registrar agrees to comply with applicable statutes and
regulations limiting the domain names that may be registered. Registrar further
acknowledges and agrees that Verisign reserves the right to deny, cancel,
redirect or transfer any registration or transaction, or place any domain
name(s) on registry lock, hold or similar status, as it deems necessary, in its
unlimited and sole discretion, for the purposes set forth in Section 2.7(b)(ii)
of this Agreement.
2.15.    ICANN Requirements. Verisign's obligations hereunder are subject to
modification at any time as the result of ICANN-mandated requirements, including
consensus policies. Notwithstanding anything in this Agreement to the contrary,
Registrar shall comply with any such ICANN requirements in accordance with the
timeline defined by ICANN.
2.16.    Accredited Registrar. During the term of this Agreement, Registrar
shall maintain in full force and effect the Registrar Accreditation Agreement
and its accreditation by ICANN as a registrar for the Registry TLD.
3.    LICENSE
3.1.    License Grant. Subject to the terms and conditions of this Agreement,
Verisign hereby grants Registrar and Registrar accepts a non-exclusive,
royalty-free, nontransferable, worldwide limited license to use for the term and
purposes of this Agreement the Licensed Product, as well as updates and
redesigns thereof, to provide domain name registration services in the Registry
TLD only and for no other purpose. The Licensed Product, as well as updates and
redesigns thereof, will enable Registrar to register domain names in the
Registry TLD with the Registry on behalf of its Registered Name Holders.
Registrar, using the Licensed Product, as well as updates and redesigns thereof,
will be able to invoke the following operations on the System: (i) check the
availability of a domain name, (ii) register a domain name, (iii) re-register a
domain name, (iv) cancel the registration of a domain name it has registered,
(v) update the nameservers of a domain name, (vi) transfer a domain name from
another registrar to itself with proper authorization, (vii) query a domain name
registration record, (viii) register a nameserver, (ix) update the IP addresses
of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and
(xii) establish and end an authenticated session.
3.2.    Limitations on Use. Notwithstanding any other provisions in this
Agreement, except with the written consent of Verisign, Registrar shall not: (i)
sublicense the Licensed Product or otherwise permit any use of the Licensed
Product by or for the benefit of any party other than Registrar, (ii) publish,
distribute or permit disclosure of the Licensed Product other than to employees,
contractors, and agents of Registrar for use in Registrar's domain name
registration business, (iii) decompile, reverse engineer, copy or re-engineer
the Licensed Product for any unauthorized purpose, (iv) use or permit use of the
Licensed Product in violation of any federal, state or local rule, regulation or
law, or for any unlawful purpose. Registrar agrees to employ the necessary
measures to prevent its access to the System granted hereunder from being used
to (i) allow, enable, or otherwise support the transmission by e-mail,
telephone, or facsimile of mass unsolicited, commercial advertising or
solicitations to entities other than Registrar's customers; or (ii) enable high
volume, automated, electronic processes that send queries or data to the systems
of Verisign, any other registry operated under an agreement with ICANN, or any
ICANN-Accredited Registrar, except as reasonably

45

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

necessary to register domain names or modify existing registrations in
accordance with any Operational Requirements.
3.3.    Changes to Licensed Materials. Verisign may from time to time replace or
make modifications to the Licensed Product licensed hereunder. Verisign will
provide Registrar with at least ninety (90) days’ notice prior to the
implementation of any material changes to the Supported Protocol, APIs or
software licensed hereunder.
4.    SUPPORT SERVICES
4.1.    Engineering Support. Verisign agrees to provide Registrar with
reasonable engineering telephone support (between the hours of 9 a.m. to 5 p.m.
EST or at such other times as may be mutually agreed upon) to address
engineering issues arising in connection with Registrar's use of the System.
4.2.    Customer Service Support. During the term of this Agreement, Verisign
will provide reasonable telephone, web based and e-mail customer service support
to Registrar, not Registered Name Holder or prospective customers of Registrar,
for nontechnical issues solely relating to the System and its operation.
Verisign will provide Registrar with a telephone number and e-mail address for
such support during implementation of the Supported Protocol, APIs and Software.
First-level telephone support will be available on a 7-day/24-hour basis.
5.    FEES
5.1.    Registration Fees.
(a)
Registrar agrees to pay Verisign the non-refundable fees set forth in Exhibit A,
or such other amount as may be established in accordance with the notice
provision set forth in Section 5.1(b) below, for initial and renewal
registrations and other incidental and ancillary services provided by Verisign
(collectively, the "Registration Fees").

(b)
Verisign reserves the right to adjust the Registration Fees, provided that any
price increase shall be made only upon six (6) months prior notice to Registrar
(by e-mail, hand, by registered mail, or by courier or express delivery
service), and provided that such adjustments are consistent with Verisign's
Registry Agreement with ICANN.

(c)
Registrars shall provide Verisign a payment security comprised of an irrevocable
letter of credit or cash deposit (the "Payment Security"). The amount of the
Payment Security establishes Registrar's credit limit in the Verisign System and
should be based on anticipated monthly level of registrations and other billable
transactions. Registrar agrees to modify its Payment Security to support
increases in billable transaction volumes as required by the Verisign credit and
billing policies. Verisign will invoice Registrar monthly in arrears for each
month's Registration Fees. All Registration Fees are due immediately upon
receipt of Verisign's monthly invoices. In order to satisfy any outstanding
account balances, Verisign may draw upon the Registrar's Payment Security. If
this occurs, Registrar agrees to replenish Payment Security to the pre-draw
level immediately upon completion of draw. If Registrar's Payment Security is
depleted, registration of domain names for the Registrar will be suspended and
new registrations will not be accepted until the Payment Security is
replenished.

46

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

(d)
The Registration Fees due under this Agreement are exclusive of tax. All taxes,
duties, fees and other governmental charges of any kind (including business,
levy, sales, turnover, services, use and value-added taxes, but excluding taxes
based on the net income of Verisign) which are imposed by or under the authority
of any government or any political subdivision thereof on the fees for any
services, software and/or hardware shall be borne by Registrar and shall not be
considered a part of, a deduction from or an offset against such Registration
Fees. All payments due to Verisign shall be made without any deduction or
withholding on account of any tax, duty, charge or penalty except as required by
law, in which case, the sum payable by Registrar from which such deduction or
withholding is to be made shall be increased to the extent necessary to ensure
that, after making such deduction or withholding, Verisign receives and retains
(free from any liability with respect thereof) a net sum equal to the sum it
would have received but for such deduction or withholding being required.

5.2.    Change in Registrar Sponsoring Domain Name. Registrar may assume
sponsorship of a Registered Name Holder's existing domain name registration from
another registrar by following the Transfer Policy.
(a)
For each transfer of the sponsorship of a domain-name registration under the
Transfer Policy, Registrar agrees to pay Verisign the renewal registration fee
associated with a one-year extension, as set forth above. The losing registrar's
Registration Fees will not be refunded as a result of any such transfer.

(b)
For a transfer approved by ICANN under Part B of the Transfer Policy, Registrar
agrees to pay Verisign US $0 (for transfers of 50,000 names or fewer) or US
$50,000 (for transfers of more than 50,000 names).

Fees under this Section 5.2 shall be due immediately upon receipt of Verisign's
invoice pursuant to the Payment Security.
5.3.    Charges for ICANN Fees. Registrar agrees to pay to Verisign, within five
(5) days of the date when due, any variable registry-level fees paid by Verisign
to ICANN, which fees shall be secured by the Payment Security. The fee will
consist of two components; each component will be calculated by ICANN for each
registrar:
(a)
The transactional component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year but shall not exceed the amount set forth in the
Registry Agreement.

(b)
The per-registrar component of the Variable Registry-Level Fee shall be
specified by ICANN in accordance with the budget adopted by the ICANN Board of
Directors for each fiscal year, but the sum of the per registrar fees calculated
for all registrars shall not exceed the total Per-Registrar Variable funding
established pursuant to the approved ICANN Budget.

5.4.    Non-Payment of Fees. Timely payment of fees owing under this Section 5
is a material condition of performance under this Agreement. In the event that
Registrar fails to pay its fees within five (5) days of the date when due,
Verisign may: (i) stop accepting new initial or renewal registrations from
Registrar; (ii) delete the domain names associated with invoices not paid in
full from the

47

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

Registry database; (iii) give written notice of termination of this Agreement
pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this
Agreement.
6.    MISCELLANEOUS
6.1.    Term of Agreement and Termination.
(a)
Term of the Agreement; Revisions. The duties and obligations of the Parties
under this Agreement shall apply from the Effective Date through and including
the last day of the calendar month sixty (60) months from the Effective Date
(the "Initial Term"). Upon conclusion of the Initial Term, all provisions of
this Agreement will automatically renew for successive five (5) year renewal
periods until the Agreement has been terminated as provided herein, Registrar
elects not to renew, or Verisign ceases to operate the registry for the Registry
TLD. In the event that revisions to Verisign's Registry-Registrar Agreement are
approved or adopted by ICANN, Registrar shall have thirty (30) days from the
date of notice of any such revision to review, comment on, and execute an
amendment substituting the revised agreement in place of this Agreement, or
Registrar may, at its option exercised within such thirty (30) day period,
terminate this Agreement immediately by giving written notice to Verisign;
provided, however, that in the event Verisign does not receive such executed
amendment or notice of termination from Registrar within such thirty (30) day
period of the date of the notice, Registrar shall be deemed to have executed
such amendment as of the thirty-first (31st) day after the date of the notice.

(b)
Termination For Cause. In the event that either Party materially breaches any
term of this Agreement including any of its representations and warranties
hereunder and such breach is not substantially cured within thirty (30) calendar
days after written notice thereof is given by the other Party, then the
non-breaching Party may, by giving written notice thereof to the other Party,
terminate this Agreement as of the date specified in such notice of termination.

(c)
Termination at Option of Registrar. Registrar may terminate this Agreement at
any time by giving Verisign thirty (30) days’ notice of termination.

(d)
Termination Upon Loss of Registrar's Accreditation. This Agreement shall
terminate immediately in the event Registrar's accreditation for the Registry
TLD by ICANN, or its successor, is terminated or expires without renewal.

(e)
Termination in the Event that Successor Registry Operator is Named. This
Agreement shall terminate in the event that the U.S. Department of Commerce or
ICANN, as appropriate, designates another entity to operate the registry for the
Registry TLD.

(f)
Termination in the Event of Bankruptcy. Either Party may terminate this
Agreement if the other Party is adjudged insolvent or bankrupt, or if
proceedings are instituted by or against a Party seeking relief, reorganization
or arrangement under any laws relating to insolvency, or seeking any assignment
for the benefit of creditors, or seeking the appointment of a receiver,
liquidator or trustee of a Party's property or assets or the liquidation,
dissolution or winding up of a Party's business.

(g)
Effect of Termination. Upon expiration or termination of this Agreement,
Verisign will, to the extent it has the authority to do so, complete the
registration of all domain names

48

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

processed by Registrar prior to the date of such expiration or termination,
provided that Registrar's payments to Verisign for Registration Fees are current
and timely. Immediately upon any expiration or termination of this Agreement,
Registrar shall (i) transfer its sponsorship of Registered Name registrations to
another licensed registrar(s) of the Registry, in compliance with Part B of the
Transfer Policy, or any other procedures established or approved by the U.S.
Department of Commerce or ICANN, as appropriate, and (ii) either return to
Verisign or certify to Verisign the destruction of all Confidential Information
it has received under this Agreement. In the event of termination, Verisign
reserves the right to immediately contact any and all Registered Name Holders to
facilitate the orderly and stable transition of Registered Name Holders to other
ICANN-accredited registrars. All fees owing to Verisign shall become immediately
due and payable.
(h)
Survival. In the event of termination of this Agreement, the following shall
survive: (i) Sections 2.6 (License), 2.7 (Registrar's Registration Agreement and
Domain Name Dispute Policy), 2.8.1 (Handling of Personal Data), 6.1(g) (Effect
of Termination), 6.1(h) (Survival), 6.2 (No Third Party Beneficiaries;
Relationship of the Parties), 6.5 (Amendment in Writing), 6.6 (Attorneys' Fees),
6.7 (Dispute Resolution; Choice of Law; Venue), 6.8 (Notices), 6.10 (Use of
Confidential Information), 6.11 (Delays or Omissions; Waivers), 6.12 (Limitation
of Liability), 6.13 (Construction), 6.14 (Intellectual Property), 6.15(c)
(Disclaimer of Warranties), 6.16 (Indemnification), and 6.17 (Entire Agreement;
Severability); (ii) the Registered Name Holder's obligations to indemnify,
defend, and hold harmless Verisign, as stated in Section 2.7(b)(iii); and (iii)
Registrar's payment obligations as set forth in Section 5 with respect to fees
incurred during the term of this Agreement.

6.2.    No Third Party Beneficiaries; Relationship of the Parties. This
Agreement does not provide and shall not be construed to provide third parties
(i.e., non-parties to this Agreement), including any Registered Name Holder,
with any remedy, claim, cause of action or privilege. Nothing in this Agreement
shall be construed as creating an employer-employee or agency relationship, a
partnership or a joint venture between the Parties.
6.3.    Force Majeure. Neither Party shall be responsible for any failure to
perform any obligation (other than payment obligations) or provide service
hereunder because of any Act of God, strike, work stoppage, cyberattack, to
protect against imminent and substantial threats to the security and stability
of the Registry TLD, System, Verisign’s name server operations or the internet,
governmental acts or directives, war, riot or civil commotion, equipment or
facilities shortages which are being experienced by providers of
telecommunications services generally, or other similar force beyond such
Party's reasonable control.
6.4.    Further Assurances. Each Party hereto shall execute and/or cause to be
delivered to each other Party hereto such instruments and other documents, and
shall take such other actions, as such other Party may reasonably request for
the purpose of carrying out or evidencing any of the transactions contemplated
by this Agreement.
6.5.    Amendment in Writing. Except as otherwise provided in this Agreement,
any amendment or supplement to this Agreement shall be in writing and duly
executed by both Parties. Any new services approved by ICANN and purchased by
Registrar will be subject to such terms and conditions as may be established by
Verisign through an appendix to this Agreement or such other agreement executed
by Registrar and Verisign.

49

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

6.6.    Attorneys' Fees. If any legal action or other legal proceeding
(including arbitration) relating to the performance under this Agreement or the
enforcement of any provision of this Agreement is brought against either Party
hereto, the prevailing Party shall be entitled to recover reasonable attorneys'
fees, costs and disbursements (in addition to any other relief to which the
prevailing Party may be entitled).
6.7.    Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to
resolve any disputes between them prior to resorting to litigation. This
Agreement is to be construed in accordance with and governed by the internal
laws of the Commonwealth of Virginia, United States of America without giving
effect to any choice of law rule that would cause the application of the laws of
any jurisdiction other than the internal laws of the Commonwealth of Virginia to
the rights and duties of the Parties. Any legal action or other legal proceeding
relating to this Agreement or the enforcement of any provision of this Agreement
shall be brought or otherwise commenced in any state or federal court located in
the eastern district of the Commonwealth of Virginia. Each Party to this
Agreement expressly and irrevocably consents and submits to the jurisdiction and
venue of each state and federal court located in the eastern district of the
Commonwealth of Virginia (and each appellate court located in the Commonwealth
of Virginia) in connection with any such legal proceeding.
6.8.    Notices. Any notice or other communication required or permitted to be
delivered to any Party under this Agreement shall be in writing and shall be
deemed properly delivered, given and received when delivered (by hand, by
registered mail, by courier or express delivery service, by e-mail or by
telecopier during business hours) to the address or telecopier number set forth
beneath the name of such Party below, unless Party has given a notice of a
change of address in writing:
if to Registrar:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:
with a copy to:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:
if to Verisign:
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Attn: General Counsel

50

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

Telephone: +1 703 948 3200
Facsimile: +1 703 435 4921
E-Mail: legal@verisign.com

With a copy to (which shall not constitute notice):

VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Attn: Customer Affairs Office
Telephone: +1 703 948 3200
Facsimile: +1 703 948 3977
E-Mail: cao@verisign-grs.com
6.9.    Assignment/Sublicense. Except as otherwise expressly provided herein,
the provisions of this Agreement shall inure to the benefit of and be binding
upon, the successors and permitted assigns of the Parties hereto. Registrar
shall not assign, sublicense or transfer its rights or obligations under this
Agreement to any third person without the prior written consent of Verisign.
Verisign may assign its rights or obligations under this Agreement to an
affiliate without the consent of Registrar.
6.9.1.    Assignment in Connection with Assignment of Agreement with ICANN. In
the event that Verisign's Registry Agreement with ICANN for the Registry TLD is
validly assigned, Verisign's rights under this Agreement shall be automatically
assigned to the assignee of the Registry Agreement, provided that the assignee
assumes the duties of Verisign under this Agreement. In the event that
Registrar's Registrar Accreditation Agreement with ICANN for the Registry TLD is
validly assigned, Registrar's rights under this Agreement shall be automatically
assigned to the assignee of Registrar’s Registrar Accreditation Agreement,
provided that the subsequent registrar assumes the duties of Registrar under
this Agreement.
6.10.    Use of Confidential Information. During the term of this Agreement,
each Party (the "Disclosing Party") may disclose its Confidential Information to
the other Party (the "Receiving Party"). Each Party's use and disclosure of
Confidential Information disclosed hereunder are subject to the following terms
and conditions:
(a)
The Receiving Party shall treat as strictly confidential, and use all reasonable
efforts to preserve the secrecy and confidentiality of, all Confidential
Information of the Disclosing Party, including implementing reasonable physical
security measures and operating procedures.

(b)
The Receiving Party agrees that it will use any Confidential Information of the
Disclosing Party solely for the purpose of exercising its right or performing
its obligations under this Agreement and for no other purposes whatsoever.

(c)
The Receiving Party shall make no disclosures whatsoever of any Confidential
Information of the Disclosing Party to others; provided, however, that if the
Receiving Party is a corporation, partnership, or similar entity, disclosure is
permitted to the Receiving Party's officers, employees, contractors and agents
who have a demonstrable need to know such

51

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

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.
(a)     IN NO EVENT WILL VERISIGN BE LIABLE TO REGISTRAR FOR ANY SPECIAL,
INDIRECT, INCIDENTAL, PUNITIVE, EXEMPLARY OR CONSEQUENTIAL DAMAGES, OR ANY
DAMAGES RESULTING FROM LOSS OF PROFITS, ARISING OUT OF OR IN CONNECTION WITH
THIS AGREEMENT, EVEN IF VERISIGN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.IN NO EVENT SHALL THE MAXIMUM AGGREGATE LIABILITY OF THE PARTIES EXCEED
THE LESSER OF (I) THE TOTAL AMOUNT PAID TO VERISIGN UNDER THE TERMS OF THIS
AGREEMENT FOR THE IMMEDIATELY PRECEDING TWELVE (12) MONTH PERIOD, OR (ii)
$500,000 USD.

52

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

(b)    THE LIABILITY CAP AND EXCLUSION OF DAMAGES SET FORTH IN SECTION 6.12(a)
SHALL NOT APPLY TO SECTION 6.10 (CONFIDENTIALITY) AND SECTION 6.16
(INDEMNIFICATION).
6.13.    Construction. The Parties agree that any rule of construction to the
effect that ambiguities are to be resolved against the drafting Party shall not
be applied in the construction or interpretation of this Agreement.
6.14.    Intellectual Property. Subject to Section 2.6 above, each Party will
continue to independently own its intellectual property, including all patents,
trademarks, trade names, service marks, copyrights, trade secrets, proprietary
processes and all other forms of intellectual property.
6.15.    Representations and Warranties
(a)
Registrar. Registrar represents and warrants that: (1) it is a corporation duly
incorporated, validly existing and in good standing under the law of
_____________, (2) it has all requisite corporate power and authority to
execute, deliver and perform its obligations under this Agreement, (3) it is,
and during the term of this Agreement will continue to be, accredited by ICANN
or its successor, pursuant to the Registrar Accreditation Agreement or a
successor agreement approved by ICANN, (4) the execution, performance and
delivery of this Agreement has been duly authorized by Registrar, and (5) no
further approval, authorization or consent of any governmental or regulatory
authority is required to be obtained or made by Registrar in order for it to
enter into and perform its obligations under this Agreement.

(b)
Verisign. Verisign represents and warrants that: (1) it is a corporation duly
incorporated, validly existing and in good standing under the laws of the State
of Delaware, (2) it has all requisite corporate power and authority to execute,
deliver and perform its obligations under this Agreement, (3) the execution,
performance and delivery of this Agreement has been duly authorized by Verisign,
and (4) no further approval, authorization or consent of any governmental or
regulatory authority is required to be obtained or made by Verisign in order for
it to enter into and perform its obligations under this Agreement.

(c)
Disclaimer of Warranties. The LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs
AND SOFTWARE ARE PROVIDED "AS-IS" AND WITHOUT ANY WARRANTY OF ANY KIND. VERISIGN
EXPRESSLY DISCLAIMS ALL WARRANTIES AND/OR CONDITIONS, EXPRESS OR IMPLIED,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES AND CONDITIONS OF
MERCHANTABILITY OR SATISFACTORY QUALITY AND FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OF THIRD PARTY RIGHTS. VERISIGN DOES NOT WARRANT THAT THE
FUNCTIONS CONTAINED IN THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR
SOFTWARE WILL MEET REGISTRAR'S REQUIREMENTS, OR THAT THE OPERATION OF THE
LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE WILL BE
UNINTERRUPTED OR ERROR-FREE, OR THAT DEFECTS IN THE LICENSED PRODUCT, SUPPORTED
PROTOCOL, EPP, APIs OR SOFTWARE WILL BE CORRECTED. FURTHERMORE, VERISIGN DOES
NOT WARRANT NOR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE
LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs, SOFTWARE OR RELATED
DOCUMENTATION IN TERMS OF THEIR CORRECTNESS,

53

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

ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE LICENSED PRODUCT, SUPPORTED
PROTOCOL, EPP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE
COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS
AND SOFTWARE.
6.16.    Indemnification. Registrar, at its own expense and within thirty (30)
days of presentation of a demand by Verisign under this paragraph, will
indemnify, defend and hold harmless Verisign and its employees, directors,
officers, representatives, agents and affiliates, against any claim, suit,
action, or other proceeding brought against Verisign or any affiliate of
Verisign based on or arising from any claim or alleged claim (i) relating to any
product or service of Registrar; (ii) relating to any agreement, including
Registrar's dispute policy, with any Registered Name Holder of Registrar; or
(iii) relating to Registrar's domain name registration business, including, but
not limited to, Registrar's advertising, domain name application process,
systems and other processes, fees charged, billing practices and customer
service; provided, however, that in any such case: (a) Verisign provides
Registrar with prompt notice of any such claim, and (b) upon Registrar's written
request, Verisign will provide to Registrar all available information and
assistance reasonably necessary for Registrar to defend such claim, provided
that Registrar reimburses Verisign for its actual and reasonable costs. Verisign
shall have the right to control the defense of Verisign to any claim or in
litigation, through counsel of its choice, whose fees shall be subject to
indemnification as provided herein. Registrar will not enter into any settlement
or compromise of any such indemnifiable claim without Verisign's prior written
consent, which consent shall not be unreasonably withheld. Registrar will pay
any and all costs, damages, and expenses, including, but not limited to,
reasonable attorneys' fees and costs awarded against or otherwise incurred by
Verisign in connection with or arising from any such indemnifiable claim, suit,
action or proceeding.
6.17.    Entire Agreement; Severability. This Agreement, which includes Exhibits
A and B, constitutes the entire agreement between the Parties concerning the
subject matter hereof and supersedes any prior agreements, representations,
statements, negotiations, understandings, proposals or undertakings, oral or
written, with respect to the subject matter expressly set forth herein. If any
provision of this Agreement shall be held to be illegal, invalid or
unenforceable, each Party agrees that such provision shall be enforced to the
maximum extent permissible so as to effect the intent of the Parties, and the
validity, legality and enforceability of the remaining provisions of this
Agreement shall not in any way be affected or impaired thereby. If necessary to
effect the intent of the Parties, the Parties shall negotiate in good faith to
amend this Agreement to replace the unenforceable language with enforceable
language that reflects such intent as closely as possible.
6.18.    Service Level Agreement. Appendix 10, as may be amended from time to
time, of the Registry Agreement shall be incorporated into this Agreement and
attached hereto as Exhibit B.

54

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

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:     

55

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

Exhibit A
REGISTRATION FEES
1.
Domain-Name Initial Registration Fee

Registrar agrees to pay US $7.85 per annual increment of an initial domain name
registration, or such other amount as may be established in accordance with the
notice provision set forth in Section 5.1(b) above.
2.
Domain-Name Renewal Fee

Registrar agrees to pay US $7.85 per annual increment of a domain name
registration renewal, or such other amount as may be established in accordance
with the notice provision set forth in Section 5.1(b) above.
3.
Domain Name Transfer

Registrar agrees to pay US $7.85 per domain name that is transferred to
Registrar from another ICANN-Accredited Registrar, or such other amount as may
be established in accordance with the notice provision set forth in Section
5.1(b) above.
4.
EPP Update to Restore a Name

Registrar agrees to pay US $40.00 per use of the EPP Update command to restore a
domain name, or such other amount as may be established in accordance with the
notice provision set forth in Section 5.1(b) above.
5.
Sync

Registrar agrees to pay US $2.00, plus $1.00 per month of the sync, for each use
of the Supported Protocol Sync command, or such other amount as may be
established in accordance with the notice provision set forth in Section 5.1(b)
above.

56

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

Exhibit B
SERVICE LEVEL AGREEMENT
See Appendix 10 to the .com Registry Agreement, as may be amended from time to
time.

57

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

.com Registry Agreement Appendix 11
Public Interest Commitments
(Effective as of the RRA Effective Date)

Registry Operator agrees to perform the following public interest commitments
beginning on the RRA Effective Date.

a. Registry Operator will ensure that there is a provision in its
Registry-Registrar Agreement that requires registrars to include in their
registration agreements a provision prohibiting Registered Name Holders from
distributing malware, abusively operating botnets, phishing, piracy, trademark
or copyright infringement, fraudulent or deceptive practices, counterfeiting or
otherwise engaging in activity contrary to applicable law, and providing
(consistent with applicable law and any related procedures) consequences (to be
enforced by the applicable registrar in accordance with such registrar’s
Registrar Accreditation Agreement) for such activities, including suspension of
the domain name.

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

58