Third Amendment to the .com Registry Agreement between VeriSign, Inc. and the Internet Corporation for Assigned Names and Numbers, entered into on March 27, 2020

EX-10.1 2 vrsn8-k32720xex101.htm EXHIBIT 10.1 Exhibit

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:

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

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

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

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 20^th 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).”

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

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

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 45^th 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 45^th 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.


(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 45^th 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 20^th 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:

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

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

. 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

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.

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.

A digital signature file will be generated for every processed file using the Registry Operator’s private key. The digital signature file will be in binary OpenPGP format as per RFC 4880 Section 9, reference 3, and will not be compressed or encrypted. The suggested algorithms for Digital signatures are DSA and RSA as per RFC 4880. The suggested algorithm for Hashes in Digital signatures is SHA256.


6)	The processed files and digital signature files will then be transferred to the Escrow Agent through secure electronic mechanisms, such as, SFTP, SCP, HTTPS file upload, etc. as agreed between the Escrow Agent and the Registry Operator. Non-electronic

delivery through a physical medium such as CD-ROMs, DVD-ROMs, or USB storage devices may be used if authorized by ICANN.


7)	The Escrow Agent will then validate every (processed) transferred data file using the procedure described in Section 8 of this Appendix.

5. File Naming Conventions. Files will be named according to the following convention: {gTLD}_{YYYY-MM-DD}_{type}_S{#}_R{rev}.{ext} where:


5.1	{gTLD} is replaced with the gTLD name; in case of an IDN-TLD, the ASCII-compatible form (A-Label) must be used;


5.2	{YYYY-MM-DD} is replaced by the date corresponding to the time used as a timeline watermark for the transactions; i.e. for the Full Deposit corresponding to 2009-08-02T00:00Z, the string to be used would be “2009-08-02”;


5.3	{type} is replaced by:


1)	“full”, if the data represents a Full Deposit;


2)	“diff”, if the data represents a Differential Deposit;


3)	“thin”, if the data represents a Bulk Registration Data Access file, as specified in Section 2.1 of Appendix 5A;


4)	"thick-{gurid}", if the data represents Thick Registration Data from a specific registrar, as defined in Section 2.2 of Appendix 5A. The {gurid} element must be replaced with the IANA Registrar ID associated with the data.


5.4	{#} is replaced by the position of the file in a series of files, beginning with “1”; in case of a lone file, this must be replaced by “1”;


5.5	{rev} is replaced by the number of revision (or resend) of the file beginning with “0”: and


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

6. Distribution of Public Keys. Each of Registry Operator and Escrow Agent will distribute its public key to the other party (Registry Operator or Escrow Agent, as the case may be) via email to an email address to be specified. Each party will confirm receipt of the other party’s public key with a reply email, and the distributing party will subsequently reconfirm the authenticity of the key transmitted via offline methods, like in person meeting, telephone, etc. In this way, public key transmission is authenticated to a user able to send and receive mail via a mail server operated by the distributing party. Escrow Agent, Registry Operator and ICANN will exchange public keys by the same procedure.

7. Notification of Deposits. Along with the delivery of each Deposit, Registry Operator will deliver to Escrow Agent and to ICANN (using the API described in draft-lozano-icann-registry-interfaces, see Section 9, reference 5 of this Appendix (the “Interface Specification”)) a written statement from Registry Operator (which may be by authenticated e-mail) that includes a copy of the report generated upon creation of the Deposit and states that the Deposit has been inspected by Registry Operator and is complete and accurate. The preparation and submission of this statement must be performed by Registry Operator or its designee, provided that such designee may not be the Escrow Agent or any of Escrow Agent’s affiliates. Registry Operator will include the Deposit’s “id” and “resend” attributes in its statement. The attributes are explained in Section 9, reference 1 of this Appendix.

If not already an RFC, Registry Operator will use the most recent draft version of the Interface Specification 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

.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

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

4.2 Delivery at Registry Operator's Request. If the provisions of Section 4.1(a) above are satisfied, Escrow Agent shall, within five (5) business days after receipt of the notification and check specified in Section 4.1(a), deliver the Deposits in accordance with the applicable instructions.

4.3 Delivery at ICANN's Request. If the provisions of Section 4.1(b) or 4.1(c) above are satisfied, Escrow Agent shall, within five (5) business days after receipt of all the documents specified in those sections, deliver the following: (i) to Registry Operator, a copy of all such documents; (ii) to ICANN, as specifically instructed by ICANN, electronic copies of the Deposits; provided, however, that if the delivery is commenced by reason of Section 4.1(c) above, Registry Operator may make the payment owing to Escrow Agent during the five (5) business day period referenced above, and Escrow Agent shall not thereafter deliver to ICANN the materials specified in subpart (ii) of this section, above. Following receipt of the notice to Registry Operator under subpart (i) of this section, Registry Operator shall have thirty (30) days from the date on which Registry Operator receives such documents ("Objection Period") to notify Escrow Agent of its objection ("Objection Notice") to the release of the Deposits to ICANN and request that the issue of entitlement to a copy of the Deposits be submitted to arbitration in accordance with the following provisions:

(a) The sending of an Objection Notice shall not delay delivery of the Deposits to ICANN.

(b) If Registry Operator shall send an Objection Notice to Escrow Agent during the Objection Period, the matter shall be submitted to and settled by arbitration by a panel of three (3) arbitrators chosen by the American Arbitration Association in accordance with the rules of the American Arbitration Association. The arbitrators shall apply the law of California exclusive of its conflicts of laws rules. At least one (1) arbitrator shall be reasonably familiar with the Internet industry. The decision of the arbitrators shall be binding and conclusive on all parties involved, and judgment upon their decision may be entered in a court of competent jurisdiction. All costs of the arbitration incurred by Escrow Agent, including reasonable attorneys' fees and costs, shall be paid by the party which does not prevail in the arbitration; provided, however, if the arbitration is settled prior to a decision by the arbitrators, the parties involved in the arbitration shall each pay an equal percentage of all such costs.

(c) Notwithstanding Section 4.3(b) above, the parties agree that any arbitration brought pursuant to this Section 4.3 shall not re-evaluate, reconsider, or otherwise subject to review any issues, causes of action, or other claims which were decided, in an arbitration or court decision involving the parties hereto concerning the Registry Agreement and/or the Cooperative Agreement, and that any decision regarding such issues or claims in an arbitration brought pursuant to Section 4.3 would be invalid, unenforceable, and not binding. The propriety, validity, legality, or effectiveness of any terminations or actions under the Registry Agreement and/or Cooperative Agreement shall be determined solely through procedures and remedies provided for by those respective agreements, not through any arbitration brought pursuant to Section 4.3. Any arbitration proceeding brought pursuant to Section 4.3 shall be limited to a determination of whether Sections 4.1(b) and (c) have been satisfied.

(d) Registry Operator may, at any time prior to the commencement of arbitration proceedings, notify Escrow Agent that Registry Operator has withdrawn the Objection Notice. Upon receipt of any such notice from Registry Operator, Escrow Agent shall promptly deliver the Deposits to ICANN in accordance with the instructions provided by ICANN.

(e) If the release of materials to ICANN pursuant to Section 4.3 is judged to be proper in any arbitration brought in accordance with Section 4.3, Escrow Agent shall promptly deliver to ICANN, in accordance with the instructions specified in Section 4.1(b)(v) above, any Deposits that have not previously been delivered. All parties agree that Escrow Agent shall not be required to deliver such Deposits until all such fees then due to Escrow Agent have been paid.

(f) If the release of the Deposits to ICANN pursuant to Section 4.3 is judged to have been improper in any arbitration brought in accordance with Section 4.3, ICANN shall promptly return or destroy, at Registry Operator's discretion, those Deposits that were received by ICANN pursuant to Section 4.3.

4.4 Delivery by Escrow Agent to Registry Operator. Escrow Agent shall release and deliver the Deposits to Registry Operator upon termination of this Escrow Agreement in accordance with Section 7(a) or 7(b) hereof.

5. Indemnity.

General Indemnity. Subject to the limitation imposed under Section 11(a) below, Registry Operator and ICANN shall jointly and severally indemnify and hold harmless Escrow Agent and each of its directors, officers, agents and employees ("Escrow Agent Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Escrow Agent Indemnitee in connection with this Escrow Agreement or the performance of Escrow Agent or any Escrow Agent Indemnitee hereunder, except for any claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, or any other expenses arising in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees or contractors. Subject to the limitation imposed under Section 11(a), Escrow Agent shall likewise

indemnify and hold harmless Registry Operator and ICANN, and each of their respective directors, officers, agents, and employees ("Indemnitees") absolutely and forever, from and against any and all claims, actions, damages, suits, liabilities, obligations, costs, fees, charges, and any other expenses whatsoever, including reasonable attorneys' fees and costs, that may be asserted by a third party against any Indemnitee in connection with the misrepresentation, negligence, or misconduct of Escrow Agent, its directors, officers, agents, employees and contractors.

6. Disputes and Interpleader.

(a) Escrow Agent may submit any dispute under this Escrow Agreement to any court of competent jurisdiction in an interpleader or similar action other than a matter submitted to arbitration after Escrow Agent's receipt of an Objection Notice under Section 4 above and the parties under this Escrow Agreement submit the matter to such arbitration as described in Section 4 of this Escrow Agreement. Any and all costs incurred by Escrow Agent in connection therewith, including reasonable attorneys' fees and costs, shall be borne 50% by each of Registry Operator and ICANN.

(b) Escrow Agent shall perform any acts ordered by any court of competent jurisdiction, without any liability or obligation to any party hereunder by reason of such act.

7. Term and Renewal.

(a) The initial term of this Escrow Agreement shall commence on the date hereof and continue until June 30, 2023 (the "Initial Term"). This Escrow Agreement shall be automatically extended for additional terms of one year (each an "Additional Term") at the end of the Initial Term and at the end of each Additional Term hereunder. The Initial Term and each Additional Term shall be referred to collectively as the “term.” Escrow Agent acting alone or Registry Operator, with the concurrence of ICANN, may terminate this Escrow Agreement at any time upon giving the other parties ninety (90) days notice.

(b) In the event Registry Operator gives notice of its intent to terminate pursuant to Section 7(a) above, and ICANN fails to concur according to Section 7(a), ICANN shall be responsible for payment of all subsequent fees and shall have the right to seek reimbursement of such fees from Registry Operator and to terminate this Escrow Agreement at any time upon giving the other parties ninety (90) days notice.

(c) In the event of termination of this Escrow Agreement in accordance with Section 7(a) or 7(b) hereof, Registry Operator shall pay all fees due Escrow Agent and shall promptly notify ICANN that this Escrow Agreement has been terminated and that Escrow Agent shall return to Registry Operator all copies of the Deposits then in its possession.

8. Fees. Registry Operator shall pay to Escrow Agent the applicable fees as compensation for Escrow Agent's services under this Escrow Agreement. The first year's fees are due upon receipt of the signed contract or Deposits, whichever comes first, and shall be paid in U.S. Dollars.

(a) Invoice Payment. After acceptance, Registry Operator shall pay valid and properly submitted invoices within thirty (30) days of the date of such invoice; provided, however, that Registry Operator shall not be obligated to pay any amounts disputed in good faith. Registry Operator shall notify Escrow Agent in writing in the event Registry Operator in good faith disputes the invoice or any portion thereof setting forth the reasons of such dispute, and the parties agree to negotiate in good faith a resolution to such disputed invoice; provided, however, that if the parties cannot reasonably agree on the disputed charges, the parties shall escalate such dispute to the appropriate director/vice president level to resolve such dispute. Payments to Escrow Agent shall be sent to the remittance address set forth on Escrow Agent’s invoice.

(b) Nonpayment. In the event of non-payment of any fees or charges invoiced by Escrow Agent, Escrow Agent shall give notice of non-payment of any fee due and payable hereunder to Registry Operator and, in such an event, Registry Operator shall have the right to pay the unpaid fee within ten (10) business

days after receipt of notice from Escrow Agent. If Registry Operator fails to pay in full all fees due during such ten (10) day period, Escrow Agent shall give notice of non-payment of any fee due and payable hereunder to ICANN and, in such event, ICANN shall have the right to pay the unpaid fee within ten (10) business days of receipt of such notice from Escrow Agent. Upon payment of the unpaid fee by either Registry Operator or ICANN, as the case may be, this Escrow Agreement shall continue in full force and effect until the end of the applicable term. Upon a failure to pay the unpaid fee under this Section 8(b) by either Registry Operator or ICANN, or by Registry Operator under Section 4.3, the Escrow Agent shall proceed as set forth in Section 4.3 as though ICANN had requested delivery of the Deposits.

(c) Invoice Submission Address. During the term of this Escrow Agreement, Escrow Agent agrees to submit detailed and timely invoices, not more frequently than once a month, and not later than ninety (90) days after the work performed under such invoice has been completed, to Registry Operator at the address set forth below as described herein. All invoices issued hereunder shall reference the Purchase Order number assigned to the work performed under this Escrow Agreement. Escrow Agent shall not submit any invoices to Registry Operator that do not reference the applicable Purchase Order number provided that Registry Operator shall be responsible for timely providing Escrow Agent such applicable Purchase Order number. Escrow Agent shall submit original invoices solely to Registry Operator’s Accounts Payable department at the mailing or electronic mailing address as set forth below:

Invoice Submission Address:

VeriSign, Inc.
12061 Bluemont Way

Reston, Virginia 20190
Attn: Accounts Payable

Or Invoices may be submitted electronically to:
***@***

9. Ownership of Deposits. The parties recognize and acknowledge that ownership of the Deposits during the effective term of this Escrow Agreement shall remain with Registry Operator at all times.

10. Retention and Confidentiality.

(a) Retention. Escrow Agent shall hold and maintain the Deposits in a secure, locked, and environmentally safe facility which is accessible only to authorized representatives of Escrow Agent. Escrow Agent shall use commercially reasonable efforts to protect the integrity of the Deposits. Each of ICANN and Registry Operator shall have the right to inspect Escrow Agent's written records with respect to this Escrow Agreement upon reasonable prior notice and during normal business hours.

(b) Confidentiality. Escrow Agent shall at all times protect the confidentiality of the Deposits. Except as provided in this Escrow Agreement, Escrow Agent shall not disclose, transfer, make available, or use any Deposits (or any copies of any Deposits). Should Escrow Agent be put on notice that it is required to disclose any Deposits by statute, rule, regulation, order, or other requirement of a governmental agency, legislative body, court of competent jurisdiction, or binding arbitral body (other than any requirement pursuant to Sections 4 or 8(b) of this Escrow Agreement), Escrow Agent shall notify ICANN and Registry Operator within seven (7) days or as soon as practicable and reasonably cooperate with Registry Operator and/or ICANN in any contest of the disclosure. Should any contest prove unsuccessful, Escrow Agent shall not be held liable for any disclosure pursuant to such governmental, legislative, judicial, or arbitral order, statute, rule, regulation, or other requirement.

11. Miscellaneous.

(a) Remedies; Limitation of Liability.

(i) Except for liability arising from (i) death or bodily injury; or (ii) gross negligence, or willful misconduct, in any dispute between Registry Operator and/or ICANN on the one hand and Escrow Agent on the other hand, all liability of Escrow Agent, Registry Operator and/or ICANN related to this Escrow Agreement, if any, whether arising in contract, tort (including negligence) or otherwise, shall be limited to an amount equal to the then annual fees paid to Escrow Agent under this Escrow Agreement.

(ii) As between Registry Operator and ICANN the liability limitations of the Registry Agreement also apply.

(iii) In no event shall any party to this Escrow Agreement be liable to another party for any incidental, special, punitive or consequential damages, lost profits, any costs or expenses for the procurement of substitute services (excluding substitute escrow services), or any other indirect damages, whether arising in contract, tort (including negligence) or otherwise even if the possibility thereof may be known in advance to one or more parties.

(iv) Each party expressly reserves all rights in law or equity to enforce the provisions of this Escrow Agreement, subject only to the limitations set forth in this Section 11(a).

(b) Permitted Reliance and Abstention. Escrow Agent may rely and shall be fully protected in acting or refraining from acting upon any notice or other document believed by Escrow Agent in good faith to be genuine and to have been signed or presented by the proper person or entity. Escrow Agent shall have no duties or responsibilities except those expressly set forth herein.

(c) Independent Contractor. Escrow Agent is an independent contractor and is not an employee or agent of either Registry Operator or ICANN.

(d) Amendments. This Escrow Agreement shall not be modified or amended except by another agreement in writing executed by each of the parties hereto.

(e) Assignment. Neither Registry Operator nor ICANN may assign or transfer this Escrow Agreement (by merger, sale of assets, operation of law, or otherwise), except that the rights and obligations of Registry Operator or ICANN automatically shall be transferred to the assignee of one of those parties' rights and obligations under the Registry Agreement. However, Escrow Agent shall have no obligation in performing this Escrow Agreement to recognize any successor or assign of Registry Operator or ICANN unless Escrow Agent receives clear, authoritative and conclusive written evidence of the change of parties. Escrow Agent may not assign or transfer this Escrow Agreement without the prior written consent of both Registry Operator and ICANN, which consent shall not be unreasonably delayed or withheld.

(f) Entire Agreement. This Escrow Agreement, including all exhibits hereto (if any), supersedes all prior discussions, understandings and agreements between Escrow Agent and the other parties with respect to the matters contained herein, and constitutes the entire agreement between Escrow Agent and the other parties with respect to the matters contemplated herein. Appendix 1A of the Registry Agreement is by this reference made a part of this Escrow Agreement and incorporated herein.

(g) Counterparts; Governing Law. This Escrow Agreement may be executed in counterparts, each of which when so executed shall be deemed to be an original and all of which when taken together shall constitute one and the same agreement. This Escrow Agreement shall be governed by and interpreted in accordance with the laws of California, without regard to its conflicts of law principles. Except as specifically provided for herein, all of the parties additionally consent to the personal jurisdiction of California, acknowledge that venue is proper in any state and Federal court in California, agree to any action related to this Escrow Agreement properly brought in one of these courts, and waive any objection it has or may have in the future with respect to any of the foregoing.

(h) Notices. All notices, requests, demands or other communications required or permitted to be given or made under this Escrow Agreement shall be in writing and shall be delivered by hand or by commercial overnight delivery service which provides for evidence of receipt, or mailed by certified mail, return receipt requested, postage prepaid. If delivered personally or by commercial overnight delivery service, the date on which the notice, request, instruction or document is delivered shall be the date on which delivery is deemed to be made, and if delivered by mail, the date on which such notice, request, instruction or document is received shall be the date on which delivery is deemed to be made. Any party may change its address for the purpose of this Escrow Agreement by notice in writing to the other parties as provided herein.

(i) Survival. Sections 5, 6, 8, 9, 10 and 11 shall survive any termination of this Escrow Agreement.

(j) No Waiver. No failure on the part of any party hereto to exercise, and no delay in exercising any right, power or single or partial exercise of any right, power or remedy by any party will preclude any other or further exercise thereof or the exercise of any other right, power or remedy. No express waiver or assent by any party hereto to any breach of or default in any term or condition of this Escrow Agreement shall constitute a waiver of or an assent to any succeeding breach of or default in the same or any other term or condition hereof.

IN WITNESS WHEREOF each of the parties has caused its duly authorized officer to execute this Escrow Agreement as of the date and year first above written.

Iron Mountain Intellectual Property Management, Inc.

By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:

_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________
_____________________________________

VeriSign, Inc.

By:
Title:
Print Name:
Address:

Phone:
Fax:

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

Internet Corporation for Assigned Names and Numbers

By:
Title:
Print Name:
Address:

Phone:
Fax:
E-mail:

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

3. TTL must be present as a decimal integer.

4. Use of \X and \DDD inside domain names is allowed.

5. All domain names must be in lower case.

6. Must use exactly one tab as separator of fields inside a record.

7. All domain names must be fully qualified.

8. No $ORIGIN directives.

9. No use of “@” to denote current origin.

10. No use of “blank domain names” at the beginning of a record to continue the use of the domain name in the previous record.

11. No $INCLUDE directives.

12. No $TTL directives.

13. No use of parentheses, e.g., to continue the list of fields in a record across a line boundary.

14. No use of comments.

15. No blank lines.

16. The SOA record should be present at the top and (duplicated at) the end of the zone file.

17. With the exception of the SOA record, all the records in a file must be in alphabetical order.

18. One zone per file. If a TLD divides its DNS data into multiple zones, each zone goes into a separate file named as above, with all the files combined using tar into a file called <tld>.zone.tar.

1.5 Use of Data by User. Registry Operator will permit user to use the zone file for lawful purposes; provided that (a) user takes all reasonable steps to protect against unauthorized access to, use of, and disclosure of the data, and (b) under no circumstances will Registry Operator be required or permitted to allow user to use the data to (i) allow, enable or otherwise support any marketing activities to entities other than the user’s existing customers, regardless of the medium used (such media include but are not limited to transmission by e-mail, telephone, facsimile, postal mail, SMS, and wireless alerts of mass unsolicited, commercial advertising or solicitations to entities), (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Registry Operator or any ICANN-accredited registrar, or (iii) interrupt, disrupt or interfere in the normal business operations of any registrant.

1.6 Term of Use. Registry Operator, through CZDA Provider, will provide each user with access to the zone file for a period of not less than three (3) months. Registry Operator will allow users to renew their Grant of Access.

1.7 No Fee for Access. Registry Operator will provide, and CZDA Provider will facilitate, access to the zone file to user at no cost.

2. Co‐operation

2.1 Assistance. Registry Operator will co-operate and provide reasonable assistance to ICANN and the CZDA Provider to facilitate and maintain the efficient access of zone file data by permitted users as contemplated under this Appendix.

2.2 ICANN Access. Registry Operator shall provide bulk access to the zone files for the TLD to ICANN or its designee on a continuous basis in the manner ICANN may reasonably specify from time to time. Access will be provided at least daily. Zone files will include SRS data committed as close as possible to 00:00:00 UTC.

.com Registry Agreement Appendix 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 < ***@***>. 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



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.



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



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



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



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



31	srs-cont-info	number of SRS (EPP and any other interface) contact “info” requests responded during the reporting period
32	srs-cont-transfer-approve	number of SRS (EPP and any other interface) contact “transfer” requests to approve transfers responded during the reporting period
33	srs-cont-transfer-cancel	number of SRS (EPP and any other interface) contact “transfer” requests to cancel transfers responded during the reporting period
34	srs-cont-transfer-query	number of SRS (EPP and any other interface) contact “transfer” requests to query about a transfer responded during the reporting period
35	srs-cont-transfer-reject	number of SRS (EPP and any other interface) contact “transfer” requests to reject transfers responded during the reporting period
36	srs-cont-transfer-request	number of SRS (EPP and any other interface) contact “transfer” requests to request transfers responded during the reporting period
37	srs-cont-update	number of SRS (EPP and any other interface) contact “update” requests responded during the reporting period
38	rdap-queries	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.

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

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.

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.


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: ***@***
Registrar Abuse Contact Phone: +1 ###-###-####
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registry Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1

Registrant Country: EX
Registrant Phone: +1 ###-###-####
Registrant Phone Ext: 1234
Registrant Fax: +1 ###-###-####
Registrant Fax Ext: 4321
Registrant Email: ***@***
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 ###-###-####
Admin Phone Ext: 1234
Admin Fax: +1 ###-###-####
Admin Fax Ext:
Admin Email: ***@***
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 ###-###-####
Tech Phone Ext: 1234
Tech Fax: +1 ###-###-####
Tech Fax Ext: 93
Tech Email: ***@***
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

Country: US
Phone Number: +1 ###-###-####
Fax Number: +1 ###-###-####
Email: ***@***
Registrar WHOIS Server: whois.example-registrar.tld
Registrar URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1 ###-###-####
Fax Number: +1 ###-###-####
Email: ***@***
Admin Contact: Jane Registrar
Phone Number: +1 ###-###-####
Fax Number: +1 ###-###-####
Email: ***@***
Technical Contact: John Geek
Phone Number: +1 ###-###-####
Fax Number: +1 ###-###-####
Email: ***@***
>>> 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.


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.

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.

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


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.

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.

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.

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

1.8. "Registered Name" refers to a domain name within the domain of the Registry TLD, whether consisting of two or more (e.g., john.smith.name) levels, about which Verisign or an affiliate engaged in providing registry services maintains data in a registry database, arranges for such maintenance, or derives revenue from such maintenance. A name in a registry database may be a Registered Name even though it does not appear in a TLD zone file (e.g., a registered but inactive name).

1.9. “Registered Name Holder(s)” means the holder(s) of a Registered Name.

1.10. “Registrar Accreditation Agreement” means that certain Registrar Accreditation Agreement between Registrar and ICANN pursuant to which ICANN has accredited Registrar to act as a registrar for one or more TLDs.

1.11. "Registry TLD" means the .COM TLD.

1.12. "Supported Protocol" means Verisign's implementation of EPP, or any successor protocols, supported by the System.

1.13. The "System" refers to the shared registration system operated by Verisign for registration of Registered Names in the Registry TLD.

1.14. A "TLD" is a top-level domain of the DNS.

2. OBLIGATIONS OF THE PARTIES

2.1. System Operation and Access. Throughout the term of this Agreement, Verisign shall operate the System and provide Registrar with access to the System to transmit domain name registration information for the Registry TLD to the System. Nothing in this Agreement entitles Registrar to enforce any agreement between Verisign and ICANN.

2.2. Maintenance of Registrations Sponsored by Registrar. Subject to the provisions of this Agreement, ICANN requirements, and Verisign requirements, including, without limitation, those authorized by ICANN, Verisign shall maintain the registrations of Registered Names sponsored by Registrar in the System during the term for which Registrar has paid the fees required by Subsection 5.1.

2.3. Distribution of EPP, APIs and Software. No later than three (3) business days after the Effective Date of this Agreement, Verisign shall make available to Registrar (i) full documentation of the Supported Protocol, (ii) "C" and/or "Java" application program interfaces ("APIs") to the Supported Protocol with documentation, and (iii) reference client software ("Software") that will allow Registrar to develop its system to register second-level domain names through the System for the Registry TLD. If Verisign elects to modify or upgrade the APIs and/or Supported Protocol, Verisign shall provide updated APIs to the Supported Protocol with documentation and updated Software to Registrar promptly as such updates become available.

2.4. Registrar Responsibility for Customer Support. Registrar shall provide (i) support to accept orders for registration, cancellation, modification, renewal, deletion or transfer of Registered Names and (ii) customer service (including domain name record support) and billing and technical support to Registered Name Holders. Registrar shall, consistent with ICANN policy, provide to Registered Name Holders emergency contact or 24/7 support information for critical situations such as domain name hijacking.

2.5. Data Submission Requirements. As part of its registration and sponsorship of Registered Names in the Registry TLD, Registrar shall submit complete data as required or permitted: (a) by Verisign’s Registry Agreement with ICANN, as may be amended from time to time; and/or (b) by technical specifications of the System that are made available to Registrar by Verisign from time to time (collectively the “Required Data Elements”). Registrar shall submit any corrections or updates from a Registered Name Holder relating to the registration information for a Registered Name to Verisign in a timely manner.

2.6. License. Registrar grants Verisign a non-exclusive, royalty-free, nontransferable (except to ICANN or its designee pursuant to Verisign’s Registry Agreement with ICANN) worldwide limited license to the Required Data Elements: (a) for use as required or permitted by technical specifications of the System as made available to Registrar by Verisign from time to time; and/or (b) for use and display as required or permitted by Verisign's Registry Agreement with ICANN, as may be amended from time to time.

2.7. Registrar's Registration Agreement and Domain Name Dispute Policy.

(a)

Registrar shall have in effect a valid and enforceable electronic or paper registration agreement with each Registered Name Holder which may be amended from time to time by Registrar, provided a copy is made available to Verisign. Registrar shall provide a copy of Registrar's registration agreement upon request for same by Verisign. Registrar shall include in its registration agreement those terms required by this Agreement and other terms that are consistent with Registrar's obligations to Verisign under this Agreement. Registrar shall employ in its domain name registration business the Uniform Domain Name Dispute Resolution Policy and the Inter-Registrar Transfer Policy, each as adopted by the ICANN Board on 26 August 1999 and 7 November 2008 and as each may be amended from time to time.


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

(i) a provision prohibiting the Registered Name Holder from distributing malware, abusively operating botnets, phishing, pharming, piracy, trademark or copyright infringement, fraudulent or deceptive practices, counterfeiting or otherwise engaging in activity contrary to applicable law and providing (consistent with applicable law and any related procedures) consequences for such activities, including suspension of the registration of the Registered Name;

(ii) a provision that requires the Registered Name Holder to acknowledge and agree that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion: (1) to comply with specifications adopted by any industry group generally recognized as authoritative with respect to the Internet (e.g., RFCs), (2) to correct mistakes made by Verisign or any Registrar in connection with a domain name registration, (3) for the non-payment of fees to Verisign, (4) to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s nameserver operations or the internet, (5) to ensure compliance with applicable law, government rules or regulations, or pursuant to any legal order or subpoena of any government, administrative or governmental authority, or court of competent jurisdiction, and/or (6) to stop or prevent any violations of any terms and

conditions of this Agreement, the Operational Requirements, or pursuant to Verisign’s Registry Agreement with ICANN; and

(iii) a provision requiring the Registered Name Holder to indemnify, defend and hold harmless Verisign and its subcontractors, and its and their directors, officers, employees, agents, and affiliates from and against any and all claims, damages, liabilities, costs and expenses, including reasonable legal fees and expenses arising out of or relating to, for any reason whatsoever, the Registered Name Holder's domain name registration. The registration agreement shall further require that this indemnification obligation survive the termination or expiration of the registration agreement.

2.8. Secure Connection.

(a)

Registrar agrees to develop and employ in its domain name registration business all necessary technology and restrictions to ensure that its connection to the System is secure. All data exchanged between Registrar's system and the System shall be protected to avoid unintended disclosure of information. Registrar shall employ commercially reasonable measures to prevent its access to the System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than its own existing customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign, any other registry operated under an agreement with ICANN, or any ICANN-accredited registrar, except as reasonably necessary to register domain names or modify existing registrations in accordance with any Operational Requirements.

(b)

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


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

2.8.1. Handling of Personal Data.

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

2.8.2. Authorization Codes. Registrar shall not provide identical Registrar-generated authorization <authinfo> codes for domain names registered by different Registered Name Holders with the same Registrar. Verisign in its sole discretion may choose to modify <authinfo> codes for a given domain and shall notify the sponsoring registrar of such modifications via EPP compliant mechanisms (i.e., EPP<poll> or EPP<domain:Info>). Documentation of these mechanisms shall be made available to Registrar by Verisign. The Registrar shall provide the Registered Name Holder with timely access to the authorization code along with the ability to modify the authorization code. Registrar shall respond to any inquiry by a Registered Name Holder regarding access to and/or modification of an authorization code within five (5) calendar days.

2.9. Domain Name Lookup Capability. Registrar agrees to employ in its domain name registration business Verisign's registry domain name lookup capability to determine if a requested domain name is available or currently unavailable for registration. Registrar also agrees, at its expense, to provide a Registration Data Directory Service providing free public query-based access to up-to-date (i.e., updated at least daily) data concerning all active Registered Names sponsored by Registrar for the Registry TLD. The data accessible shall consist of elements that are designated from time to time according to an ICANN adopted specification or policy or the Registrar Accreditation Agreement between Registrar and ICANN.

2.10. Transfer of Sponsorship of Registrations. Registrar agrees to implement transfers of Registered Name registrations from another registrar to Registrar and vice versa or from one Registered Name Holder to another pursuant to the Inter-Registrar Transfer Policy as may be amended from time to time by ICANN (the "Transfer Policy").

2.11. Time. Registrar agrees that in the event of any dispute concerning the time of the entry of a domain name registration into the registry database, the time shown in the Verisign records shall control.

2.12. Compliance with Operational Requirements. Registrar shall comply with each of the following requirements, and further shall include in its registration agreement with each Registered Name Holder, as applicable, an obligation for such Registered Name Holder to comply with each of the following requirements:


(a)	ICANN standards, policies, procedures, and practices for which Verisign has monitoring responsibility in accordance with the Registry Agreement or other arrangement with ICANN; and

(b)

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

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

temporarily suspend or restrict access to the System. Such temporary suspensions or restrictions shall be applied in a non-arbitrary manner and shall apply fairly to any registrar similarly situated.

2.14. Prohibited Domain Name Registrations. In addition to complying with ICANN standards, policies, procedures, and practices limiting domain names that may be registered, Registrar agrees to comply with applicable statutes and regulations limiting the domain names that may be registered. Registrar further acknowledges and agrees that Verisign reserves the right to deny, cancel, redirect or transfer any registration or transaction, or place any domain name(s) on registry lock, hold or similar status, as it deems necessary, in its unlimited and sole discretion, for the purposes set forth in Section 2.7(b)(ii) of this Agreement.

2.15. ICANN Requirements. Verisign's obligations hereunder are subject to modification at any time as the result of ICANN-mandated requirements, including consensus policies. Notwithstanding anything in this Agreement to the contrary, Registrar shall comply with any such ICANN requirements in accordance with the timeline defined by ICANN.

2.16. Accredited Registrar. During the term of this Agreement, Registrar shall maintain in full force and effect the Registrar Accreditation Agreement and its accreditation by ICANN as a registrar for the Registry TLD.

3. LICENSE

3.1. License Grant. Subject to the terms and conditions of this Agreement, Verisign hereby grants Registrar and Registrar accepts a non-exclusive, royalty-free, nontransferable, worldwide limited license to use for the term and purposes of this Agreement the Licensed Product, as well as updates and redesigns thereof, to provide domain name registration services in the Registry TLD only and for no other purpose. The Licensed Product, as well as updates and redesigns thereof, will enable Registrar to register domain names in the Registry TLD with the Registry on behalf of its Registered Name Holders. Registrar, using the Licensed Product, as well as updates and redesigns thereof, will be able to invoke the following operations on the System: (i) check the availability of a domain name, (ii) register a domain name, (iii) re-register a domain name, (iv) cancel the registration of a domain name it has registered, (v) update the nameservers of a domain name, (vi) transfer a domain name from another registrar to itself with proper authorization, (vii) query a domain name registration record, (viii) register a nameserver, (ix) update the IP addresses of a nameserver, (x) delete a nameserver, (xi) query a nameserver, and (xii) establish and end an authenticated session.

3.2. Limitations on Use. Notwithstanding any other provisions in this Agreement, except with the written consent of Verisign, Registrar shall not: (i) sublicense the Licensed Product or otherwise permit any use of the Licensed Product by or for the benefit of any party other than Registrar, (ii) publish, distribute or permit disclosure of the Licensed Product other than to employees, contractors, and agents of Registrar for use in Registrar's domain name registration business, (iii) decompile, reverse engineer, copy or re-engineer the Licensed Product for any unauthorized purpose, (iv) use or permit use of the Licensed Product in violation of any federal, state or local rule, regulation or law, or for any unlawful purpose. Registrar agrees to employ the necessary measures to prevent its access to the System granted hereunder from being used to (i) allow, enable, or otherwise support the transmission by e-mail, telephone, or facsimile of mass unsolicited, commercial advertising or solicitations to entities other than Registrar's customers; or (ii) enable high volume, automated, electronic processes that send queries or data to the systems of Verisign, any other registry operated under an agreement with ICANN, or any ICANN-Accredited Registrar, except as reasonably

necessary to register domain names or modify existing registrations in accordance with any Operational Requirements.

3.3. Changes to Licensed Materials. Verisign may from time to time replace or make modifications to the Licensed Product licensed hereunder. Verisign will provide Registrar with at least ninety (90) days’ notice prior to the implementation of any material changes to the Supported Protocol, APIs or software licensed hereunder.

4. SUPPORT SERVICES

4.1. Engineering Support. Verisign agrees to provide Registrar with reasonable engineering telephone support (between the hours of 9 a.m. to 5 p.m. EST or at such other times as may be mutually agreed upon) to address engineering issues arising in connection with Registrar's use of the System.

4.2. Customer Service Support. During the term of this Agreement, Verisign will provide reasonable telephone, web based and e-mail customer service support to Registrar, not Registered Name Holder or prospective customers of Registrar, for nontechnical issues solely relating to the System and its operation. Verisign will provide Registrar with a telephone number and e-mail address for such support during implementation of the Supported Protocol, APIs and Software. First-level telephone support will be available on a 7-day/24-hour basis.

5. FEES

5.1. Registration Fees.


(a)	Registrar agrees to pay Verisign the non-refundable fees set forth in Exhibit A, or such other amount as may be established in accordance with the notice provision set forth in Section 5.1(b) below, for initial and renewal registrations and other incidental and ancillary services provided by Verisign (collectively, the "Registration Fees").


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

(c)

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

(d)

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

5.2. Change in Registrar Sponsoring Domain Name. Registrar may assume sponsorship of a Registered Name Holder's existing domain name registration from another registrar by following the Transfer Policy.


(a)	For each transfer of the sponsorship of a domain-name registration under the Transfer Policy, Registrar agrees to pay Verisign the renewal registration fee associated with a one-year extension, as set forth above. The losing registrar's Registration Fees will not be refunded as a result of any such transfer.


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

Fees under this Section 5.2 shall be due immediately upon receipt of Verisign's invoice pursuant to the Payment Security.

5.3. Charges for ICANN Fees. Registrar agrees to pay to Verisign, within five (5) days of the date when due, any variable registry-level fees paid by Verisign to ICANN, which fees shall be secured by the Payment Security. The fee will consist of two components; each component will be calculated by ICANN for each registrar:


(a)	The transactional component of the Variable Registry-Level Fee shall be specified by ICANN in accordance with the budget adopted by the ICANN Board of Directors for each fiscal year but shall not exceed the amount set forth in the Registry Agreement.


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

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

Registry database; (iii) give written notice of termination of this Agreement pursuant to Section 6.1(b) below; and (iv) pursue any other remedy under this Agreement.

6. MISCELLANEOUS

6.1. Term of Agreement and Termination.

(a)

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

(b)

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


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


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


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

(f)

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


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

processed by Registrar prior to the date of such expiration or termination, provided that Registrar's payments to Verisign for Registration Fees are current and timely. Immediately upon any expiration or termination of this Agreement, Registrar shall (i) transfer its sponsorship of Registered Name registrations to another licensed registrar(s) of the Registry, in compliance with Part B of the Transfer Policy, or any other procedures established or approved by the U.S. Department of Commerce or ICANN, as appropriate, and (ii) either return to Verisign or certify to Verisign the destruction of all Confidential Information it has received under this Agreement. In the event of termination, Verisign reserves the right to immediately contact any and all Registered Name Holders to facilitate the orderly and stable transition of Registered Name Holders to other ICANN-accredited registrars. All fees owing to Verisign shall become immediately due and payable.

(h)

Survival. In the event of termination of this Agreement, the following shall survive: (i) Sections 2.6 (License), 2.7 (Registrar's Registration Agreement and Domain Name Dispute Policy), 2.8.1 (Handling of Personal Data), 6.1(g) (Effect of Termination), 6.1(h) (Survival), 6.2 (No Third Party Beneficiaries; Relationship of the Parties), 6.5 (Amendment in Writing), 6.6 (Attorneys' Fees), 6.7 (Dispute Resolution; Choice of Law; Venue), 6.8 (Notices), 6.10 (Use of Confidential Information), 6.11 (Delays or Omissions; Waivers), 6.12 (Limitation of Liability), 6.13 (Construction), 6.14 (Intellectual Property), 6.15(c) (Disclaimer of Warranties), 6.16 (Indemnification), and 6.17 (Entire Agreement; Severability); (ii) the Registered Name Holder's obligations to indemnify, defend, and hold harmless Verisign, as stated in Section 2.7(b)(iii); and (iii) Registrar's payment obligations as set forth in Section 5 with respect to fees incurred during the term of this Agreement.

6.2. No Third Party Beneficiaries; Relationship of the Parties. This Agreement does not provide and shall not be construed to provide third parties (i.e., non-parties to this Agreement), including any Registered Name Holder, with any remedy, claim, cause of action or privilege. Nothing in this Agreement shall be construed as creating an employer-employee or agency relationship, a partnership or a joint venture between the Parties.

6.3. Force Majeure. Neither Party shall be responsible for any failure to perform any obligation (other than payment obligations) or provide service hereunder because of any Act of God, strike, work stoppage, cyberattack, to protect against imminent and substantial threats to the security and stability of the Registry TLD, System, Verisign’s name server operations or the internet, governmental acts or directives, war, riot or civil commotion, equipment or facilities shortages which are being experienced by providers of telecommunications services generally, or other similar force beyond such Party's reasonable control.

6.4. Further Assurances. Each Party hereto shall execute and/or cause to be delivered to each other Party hereto such instruments and other documents, and shall take such other actions, as such other Party may reasonably request for the purpose of carrying out or evidencing any of the transactions contemplated by this Agreement.

6.5. Amendment in Writing. Except as otherwise provided in this Agreement, any amendment or supplement to this Agreement shall be in writing and duly executed by both Parties. Any new services approved by ICANN and purchased by Registrar will be subject to such terms and conditions as may be established by Verisign through an appendix to this Agreement or such other agreement executed by Registrar and Verisign.

6.6. Attorneys' Fees. If any legal action or other legal proceeding (including arbitration) relating to the performance under this Agreement or the enforcement of any provision of this Agreement is brought against either Party hereto, the prevailing Party shall be entitled to recover reasonable attorneys' fees, costs and disbursements (in addition to any other relief to which the prevailing Party may be entitled).

6.7. Dispute Resolution; Choice of Law; Venue. The Parties shall attempt to resolve any disputes between them prior to resorting to litigation. This Agreement is to be construed in accordance with and governed by the internal laws of the Commonwealth of Virginia, United States of America without giving effect to any choice of law rule that would cause the application of the laws of any jurisdiction other than the internal laws of the Commonwealth of Virginia to the rights and duties of the Parties. Any legal action or other legal proceeding relating to this Agreement or the enforcement of any provision of this Agreement shall be brought or otherwise commenced in any state or federal court located in the eastern district of the Commonwealth of Virginia. Each Party to this Agreement expressly and irrevocably consents and submits to the jurisdiction and venue of each state and federal court located in the eastern district of the Commonwealth of Virginia (and each appellate court located in the Commonwealth of Virginia) in connection with any such legal proceeding.

6.8. Notices. Any notice or other communication required or permitted to be delivered to any Party under this Agreement shall be in writing and shall be deemed properly delivered, given and received when delivered (by hand, by registered mail, by courier or express delivery service, by e-mail or by telecopier during business hours) to the address or telecopier number set forth beneath the name of such Party below, unless Party has given a notice of a change of address in writing:

if to Registrar:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:

with a copy to:
Customer Name:
Attention:
Physical Address:
City, State Postal:
Telephone Number:
Facsimile Number:
E-Mail:

if to Verisign:
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Attn: General Counsel

Telephone: +1 ###-###-####
Facsimile: +1 ###-###-####
E-Mail: ***@***

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

VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
Attn: Customer Affairs Office

Telephone: +1 ###-###-####
Facsimile: +1 ###-###-####
E-Mail: ***@***

6.9. Assignment/Sublicense. Except as otherwise expressly provided herein, the provisions of this Agreement shall inure to the benefit of and be binding upon, the successors and permitted assigns of the Parties hereto. Registrar shall not assign, sublicense or transfer its rights or obligations under this Agreement to any third person without the prior written consent of Verisign. Verisign may assign its rights or obligations under this Agreement to an affiliate without the consent of Registrar.

6.9.1. Assignment in Connection with Assignment of Agreement with ICANN. In the event that Verisign's Registry Agreement with ICANN for the Registry TLD is validly assigned, Verisign's rights under this Agreement shall be automatically assigned to the assignee of the Registry Agreement, provided that the assignee assumes the duties of Verisign under this Agreement. In the event that Registrar's Registrar Accreditation Agreement with ICANN for the Registry TLD is validly assigned, Registrar's rights under this Agreement shall be automatically assigned to the assignee of Registrar’s Registrar Accreditation Agreement, provided that the subsequent registrar assumes the duties of Registrar under this Agreement.

6.10. Use of Confidential Information. During the term of this Agreement, each Party (the "Disclosing Party") may disclose its Confidential Information to the other Party (the "Receiving Party"). Each Party's use and disclosure of Confidential Information disclosed hereunder are subject to the following terms and conditions:


(a)	The Receiving Party shall treat as strictly confidential, and use all reasonable efforts to preserve the secrecy and confidentiality of, all Confidential Information of the Disclosing Party, including implementing reasonable physical security measures and operating procedures.


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


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

Confidential Information, provided the Receiving Party shall advise such personnel of the confidential nature of the Confidential Information and take reasonable steps to maintain the confidentiality thereof.


(d)	The Receiving Party shall not modify or remove any confidentiality legends and/or copyright notices appearing on any Confidential Information of the Disclosing Party.


(e)	The Receiving Party agrees not to prepare any derivative works based on the Confidential Information.

(f)

Notwithstanding the foregoing, this Subsection 6.10 imposes no obligation upon the parties with respect to information that (i) is disclosed in the absence of a confidentiality agreement and such disclosure was agreed to by the Disclosing Party in writing prior to such disclosure; or (ii) is or has entered the public domain through no fault of the Receiving Party; or (iii) is known by the Receiving Party prior to the time of disclosure; or (iv) is independently developed by the Receiving Party without use of the Confidential 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.

(b) THE LIABILITY CAP AND EXCLUSION OF DAMAGES SET FORTH IN SECTION 6.12(a) SHALL NOT APPLY TO SECTION 6.10 (CONFIDENTIALITY) AND SECTION 6.16 (INDEMNIFICATION).

6.13. Construction. The Parties agree that any rule of construction to the effect that ambiguities are to be resolved against the drafting Party shall not be applied in the construction or interpretation of this Agreement.

6.14. Intellectual Property. Subject to Section 2.6 above, each Party will continue to independently own its intellectual property, including all patents, trademarks, trade names, service marks, copyrights, trade secrets, proprietary processes and all other forms of intellectual property.

6.15. Representations and Warranties

(a)

Registrar. Registrar represents and warrants that: (1) it is a corporation duly incorporated, validly existing and in good standing under the law of _____________, (2) it has all requisite corporate power and authority to execute, deliver and perform its obligations under this Agreement, (3) it is, and during the term of this Agreement will continue to be, accredited by ICANN or its successor, pursuant to the Registrar Accreditation Agreement or a successor agreement approved by ICANN, (4) the execution, performance and delivery of this Agreement has been duly authorized by Registrar, and (5) no further approval, authorization or consent of any governmental or regulatory authority is required to be obtained or made by Registrar in order for it to enter into and perform its obligations under this Agreement.

(b)

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

(c)

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

ACCURACY, RELIABILITY, OR OTHERWISE. SHOULD THE LICENSED PRODUCT, SUPPORTED PROTOCOL, EPP, APIs OR SOFTWARE PROVE DEFECTIVE, REGISTRAR ASSUMES THE ENTIRE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION OF REGISTRAR'S OWN SYSTEMS AND SOFTWARE.

6.16. Indemnification. Registrar, at its own expense and within thirty (30) days of presentation of a demand by Verisign under this paragraph, will indemnify, defend and hold harmless Verisign and its employees, directors, officers, representatives, agents and affiliates, against any claim, suit, action, or other proceeding brought against Verisign or any affiliate of Verisign based on or arising from any claim or alleged claim (i) relating to any product or service of Registrar; (ii) relating to any agreement, including Registrar's dispute policy, with any Registered Name Holder of Registrar; or (iii) relating to Registrar's domain name registration business, including, but not limited to, Registrar's advertising, domain name application process, systems and other processes, fees charged, billing practices and customer service; provided, however, that in any such case: (a) Verisign provides Registrar with prompt notice of any such claim, and (b) upon Registrar's written request, Verisign will provide to Registrar all available information and assistance reasonably necessary for Registrar to defend such claim, provided that Registrar reimburses Verisign for its actual and reasonable costs. Verisign shall have the right to control the defense of Verisign to any claim or in litigation, through counsel of its choice, whose fees shall be subject to indemnification as provided herein. Registrar will not enter into any settlement or compromise of any such indemnifiable claim without Verisign's prior written consent, which consent shall not be unreasonably withheld. Registrar will pay any and all costs, damages, and expenses, including, but not limited to, reasonable attorneys' fees and costs awarded against or otherwise incurred by Verisign in connection with or arising from any such indemnifiable claim, suit, action or proceeding.

6.17. Entire Agreement; Severability. This Agreement, which includes Exhibits A and B, constitutes the entire agreement between the Parties concerning the subject matter hereof and supersedes any prior agreements, representations, statements, negotiations, understandings, proposals or undertakings, oral or written, with respect to the subject matter expressly set forth herein. If any provision of this Agreement shall be held to be illegal, invalid or unenforceable, each Party agrees that such provision shall be enforced to the maximum extent permissible so as to effect the intent of the Parties, and the validity, legality and enforceability of the remaining provisions of this Agreement shall not in any way be affected or impaired thereby. If necessary to effect the intent of the Parties, the Parties shall negotiate in good faith to amend this Agreement to replace the unenforceable language with enforceable language that reflects such intent as closely as possible.

6.18. Service Level Agreement. Appendix 10, as may be amended from time to time, of the Registry Agreement shall be incorporated into this Agreement and attached hereto as Exhibit B.

IN WITNESS WHEREOF, the Parties hereto have executed this Agreement as of the Effective Date.

Verisign

By:

Name:

Title:

Date:

Registrar

Company Name:

By:

Name:

Title:

Date:

Exhibit A

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.

Exhibit B

SERVICE LEVEL AGREEMENT

See Appendix 10 to the .com Registry Agreement, as may be amended from time to time.

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