FIRST AMENDMENT TO THE .NET REGISTRY AGREEMENT
Exhibit 10.01
FIRST AMENDMENT TO THE .NET REGISTRY AGREEMENT
This FIRST AMENDMENT TO THE .NET REGISTRY AGREEMENT (“Amendment 1”) is dated as of 27 April 2020 (the “Amendment 1 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 .net Registry Agreement effective as of July 1, 2017 (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 Section 3.1(c)(iv) (Monthly Reporting) of the Agreement to negotiate in good faith to develop a transition plan setting forth the timing and process by which Registry Operator would deliver the monthly operator’s reports with the content and format set forth in Specification 3 of the new gTLD registry agreement;
WHEREAS, the Parties agree that this Amendment 1 satisfies each Party’s obligations under Section 3.1(c)(iv); 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 1, and other good and valuable consideration the receipt and sufficiency of which is hereby acknowledged, the Parties agree as follows:
1.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 (Monthly Operators Reports). Notwithstanding the foregoing, beginning on June 20, 2020, Appendix 4 (Monthly Operators Reports) shall be deleted in its entirety and replaced with Appendix 4A (Format and Content for Registry Operator Monthly Reporting), attached hereto and incorporated herein by this reference, and no later than the 20th calendar day of each calendar month thereafter, Registry Operator shall prepare and deliver to ICANN reports providing such data and in the format set forth in Appendix 4A (Format and Content for Registry Operator Monthly Reporting).”
2. The Parties agree that, effective as of June 20, 2020, Appendix 4 (Monthly Operators Reports) 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 Appendix4 (Monthly Operators Reports) shall refer to Appendix 4A (Format and Content for Registry Operator Monthly Reporting).
3. The Parties agree that the title of Section 7.2(a) (Registry-Level Transaction Fee) of the Agreement shall be deleted and replaced in its entirety as follows:
“7.2(a) Registry-Level Transaction Fee and Sync Transaction Fee.”
4. The Parties agree to add the following to the end of Section 7.2(a) (Registry-Level Transaction Fee) of the Agreement:
1
“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.75, based on the number of days the domain name registration is extended past its expiry date through the Sync Service (“Sync Transaction Fee”). 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.”
5. The Parties agree that Section 7.2(b) (Payment Schedule) of the Agreement shall be deleted and replaced in its entirety as follows:
“7.2(b) Payment Schedule. Registry Operator shall pay the Registry-Level Transaction Fees and Sync Transaction Fees specified in Section 7.2(a), the Fixed Registry-Level Fees specified in Section 7.2(c), and the Variable Registry-Level Fees specified in Section 7.2(d), if applicable, by the 20th calendar day following the end of each calendar quarter (i.e., on April 20, July 20, October 20 and January 20 for the calendar quarters ending March 31, June 30, September 30 and December 31) of the year to an account designated by ICANN.”
6. 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;”
7. Agreement; No Other Amendment; Reaffirmation. Except as amended by this Amendment 1, 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 1 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 1, and that all references in such document to the Agreement shall mean and include the Agreement as amended hereby.
8. Incorporation by Reference. This Amendment 1 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.
2
IN WITNESS WHEREOF, ICANN and Verisign have caused this Amendment 1 to be executed and delivered by their duly authorized officers as of the Amendment 1 Effective Date.
| INTERNET CORPORATION FOR ASSIGNED NAMES AND NUMBERS | ||||||||
By: /s/ Xxxxx Xxxxx | ||||||||
Name: Xxxxx Xxxxx | ||||||||
| Title: President and Chief Executive Officer | ||||||||
Date: 27 April 2020 | ||||||||
VERISIGN, INC. | ||||||||
| By: /s/ D. Xxxxx Xxxxxx | ||||||||
| Name: D. Xxxxx Xxxxxx | ||||||||
| Title: President and Chief Executive Officer | ||||||||
Date: 27 April 2020 | ||||||||
3
.net 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
<xxxxxxxxxxxxxxx@xxxxx.xxx>. The Per-Registrar Transactions Reports and the Registry Functions Activity Reports shall be submitted to ICANN using the API described in draft- xxxxxx-icann-registry-interfaces, see xxxxx://xxxxx.xxxx.xxx/xxxx/xxxxx-xxxxxx-xxxxx-xxxxxxxx- 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 | ||||||
| 01 | registrar-name | Registrar’s full corporate name as registered with IANA | ||||||
| 02 | iana-id | For cases where the registry operator acts as registrar (i.e., without the use of an ICANN accredited registrar) either 9998 or 9999 should be used depending on registration type, otherwise the sponsoring Registrar IANA id should be used as specified in xxxx://xxx.xxxx.xxx/xxxxxxxxxxx/xxxxxxxxx-xxx | ||||||
| 03 | total-domains | total domain names under sponsorship in any EPP status but pendingCreate that have not been purged | ||||||
| 04 | total-nameservers | total name servers (either host objects or name server hosts as domain name attributes) associated with domain names registered for the TLD in any EPP status but pendingCreate that have not been purged | ||||||
4
| 05 | net-adds-1-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of one (1) year (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 06 | net-adds-2-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of two(2) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 07 | net-adds-3-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of three (3) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 08 | net-adds-4-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of four (4) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 09 | net-adds-5-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of five (5) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 10 | net-adds-6-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of six (6) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 11 | net-adds-7-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of seven (7) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 12 | net-adds-8-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of eight (8) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 13 | net-adds-9-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of nine (9) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 14 | net-adds-10-yr | number of domains successfully registered (i.e., not in EPP pendingCreate status) with an initial term of ten (10) years (and not deleted within the add grace period). A transaction must be reported in the month the add grace period ends. | ||||||
| 15 | net-renews-1-yr | number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of one (1) year (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends. | ||||||
| 16 | net-renews-2-yr | number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of two (2) years (and not deleted within the renew or auto-renew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends. | ||||||
| 17 | net-renews-3-yr | number of domains successfully renewed (i.e., not in EPP pendingRenew status) either automatically or by command with a new renewal period of three (3) years (and not deleted within the renew or autorenew grace period). A transaction must be reported in the month the renew or auto-renew grace period ends. | ||||||
5
| 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 autorenew 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 autorenew 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 autorenew 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 autorenew 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. | ||||||
6
| 33 | deleted-domains-nograce | domains deleted outside the add grace period (does not include names deleted while in EPP pendingCreate status). A deletion must be reported in the month the name is purged. | ||||||
| 34 | restored-domains | domain names restored during reporting period | ||||||
| 35 | restored-noreport | total number of restored names for which a restore report is required by the registry, but the registrar failed to submit it | ||||||
| 36 | agp-exemption-requests | total number of AGP (add grace period) exemption requests | ||||||
| 37 | agp-exemptions-granted | total number of AGP (add grace period) exemption requests granted | ||||||
| 38 | agp-exempted-domains | total number of names affected by granted AGP (add grace period) exemption requests | ||||||
| 39 | attempted-adds | number of attempted (both successful and failed) domain name create commands | ||||||
| 40 | consolidate-transaction-days | total number of days added to the expiration date of all domain names via consolidate/sync transactions. The number of days of a consolidate/sync transaction must be reported here in the month the transaction took place. | ||||||
| 41 | consolidate-transactions | total number of consolidate/sync transactions. A transaction must be reported in the month the transaction took place. | ||||||
The first line shall include the field names exactly as described in the table above as a “header line” as described in section 2 of RFC 4180. The last line of each report shall include totals for each column across all registrars; the first field of this line shall read “Totals” while the second field shall be left empty in that line. No other lines besides the ones described above shall be included. Line breaks shall be <U+000D, U+00A> as described in XXX 0000.
3. Registry Functions Activity Report. This report shall be compiled in a comma separated value formatted file as specified in RFC4180. The file shall be named “net-activityyyyymm.csv.” The file shall contain the following fields:
| Field # | Field Name | Description | ||||||
| 01 | operational-registrars | number of operational registrars in the production system at the end of the reporting period | ||||||
| 02 | zfa-passwords | number of active zone file access passwords at the end of the reporting period; "CZDS" may be used instead of the number of active zone file access passwords, if the Centralized Zone Data Service (CZDS) is used to provide the zone file to the end user | ||||||
| 03 | whois-43-queries | number of WHOIS (port-43) queries responded during the reporting period | ||||||
| 04 | web-whois-queries | number of Web-based Whois queries responded during the reporting period, not including searchable Whois | ||||||
| 05 | searchable-whois-queries | number of searchable Whois queries responded during the reporting period, if offered | ||||||
| 06 | dns-udp-queries-received | number of DNS queries received over UDP transport during the reporting period | ||||||
| 07 | dns-udp-queries-responded | number of DNS queries received over UDP transport that were responded during the reporting period | ||||||
7
| 08 | dns-tcp-queries-received | number of DNS queries received over TCP transport during the reporting period | ||||||
| 09 | dns-tcp-queries-responded | number of DNS queries received over TCP transport that were responded during the reporting period | ||||||
| 10 | srs-dom-check | number of SRS (EPP and any other interface) domain name “check” requests responded during the reporting period | ||||||
| 11 | srs-dom-create | number of SRS (EPP and any other interface) domain name “create” requests responded during the reporting period | ||||||
| 12 | srs-dom-delete | number of SRS (EPP and any other interface) domain name “delete” requests responded during the reporting period | ||||||
| 13 | srs-dom-info | number of SRS (EPP and any other interface) domain name “info” requests responded during the reporting period | ||||||
| 14 | srs-dom-renew | number of SRS (EPP and any other interface) domain name “renew” requests responded during the reporting period | ||||||
| 15 | srs-dom-rgp-restore-report | number of SRS (EPP and any other interface) domain name RGP “restore” requests delivering a restore report responded during the reporting period | ||||||
| 16 | srs-dom-rgp-restore-request | number of SRS (EPP and any other interface) domain name RGP “restore” requests responded during the reporting period | ||||||
| 17 | srs-dom-transfer-approve | number of SRS (EPP and any other interface) domain name “transfer” requests to approve transfers responded during the reporting period | ||||||
| 18 | srs-dom-transfer-cancel | number of SRS (EPP and any other interface) domain name “transfer” requests to cancel transfers responded during the reporting period | ||||||
| 19 | srs-dom-transfer-query | number of SRS (EPP and any other interface) domain name “transfer” requests to query about a transfer responded during the reporting period | ||||||
| 20 | srs-dom-transfer-reject | number of SRS (EPP and any other interface) domain name “transfer” requests to reject transfers responded during the reporting period | ||||||
| 21 | srs-dom-transfer-request | number of SRS (EPP and any other interface) domain name “transfer” requests to request transfers responded during the reporting period | ||||||
| 22 | srs-dom-update | number of SRS (EPP and any other interface) domain name “update” requests (not including RGP restore requests) responded during the reporting period | ||||||
| 23 | srs-host-check | number of SRS (EPP and any other interface) host “check” requests responded during the reporting period | ||||||
| 24 | srs-host-create | number of SRS (EPP and any other interface) host “create” requests responded during the reporting period | ||||||
| 25 | srs-host-delete | number of SRS (EPP and any other interface) host “delete” requests responded during the reporting period | ||||||
| 26 | srs-host-info | number of SRS (EPP and any other interface) host “info” requests responded during the reporting period | ||||||
| 27 | srs-host-update | number of SRS (EPP and any other interface) host “update” requests responded during the reporting period | ||||||
8
| 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 | ||||||
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.
9
