This 2023 Global Amendment to Registry Agreements (this “2023 Amendment”), effective as of 7 August 2023, amends the registry agreements listed on Schedule A (the “Applicable Registry Agreements”) entered into between Internet Corporation for Assigned Names and Numbers, a California nonprofit public benefit corporation (“ICANN”), and the Applicable Registry Operators party to such Applicable Registry Agreements. This 2023 Amendment is made and is effective pursuant to Section 7.7 of the Applicable Registry Agreements. Capitalized terms used and not defined in this 2023 Amendment will have the respective meanings given thereto in the Applicable Registry Agreements.
WHEREAS, the Applicable Registry Agreements may be amended pursuant to the requirements of and process set forth in Section 7.7 of the Applicable Registry Agreements;
WHEREAS, ICANN and the Working Group have consulted in good faith regarding the form and substance of this 2023 Amendment;
WHEREAS, ICANN has publicly posted this 2023 Amendment on its website for no less than 30 calendar days and has provided notice of this 2023 Amendment to the Applicable Registry Operators in accordance with Section 7.9 of the Applicable Registry Agreements;
WHEREAS, ICANN and the Working Group have considered the public comments submitted on this 2023 Amendment during the Posting Period;
WHEREAS, on 30 April 2023, this 2023 Amendment was approved by the ICANN Board of Directors;
WHEREAS, on 20 March 2023, this 2023 Amendment received Registry Operator Approval;
WHEREAS, on 8 June 2023, ICANN provided the Applicable Registry Operators with notice that this 2023 Amendment was an Approved Amendment (the “2023 Amendment Notice Date”); and
WHEREAS, pursuant to Section 7.7(c) of the Applicable Registry Agreements, this 2023 Amendment will, without any further action by ICANN or the Applicable Registry Operators, be effective and deemed an amendment to the Applicable Registry Agreements on 7 August 2023 (the “2023 Amendment Effective Date”), the date that is 60 calendar days from the 2023 Amendment Notice Date.
NOW, THEREFORE, in consideration of the above recitals acknowledged herein by reference, this 2023 Amendment will be deemed an effective amendment to each of the Applicable Registry Agreements as of the 2023 Amendment Effective Date.
1. Section 2.1 is hereby amended and restated in its entirety as follows:
2.1 Approved Services; Additional Services. Registry Operator shall be entitled to provide the Registry Services described in clauses (a) and (b) of the first paragraph of Section 2.1 in the Specification 6 attached hereto (“Specification 6”) and such other Registry Services set forth on Exhibit A (collectively, the “Approved Services”). If Registry Operator desires to provide any Registry Service that is not an Approved Service or is a material modification to an Approved Service (each, an “Additional Service”), Registry Operator shall submit a request for approval of such Additional Service pursuant to the Registry Services Evaluation Policy at https://www.icann.org/rsep, as such policy may be amended from time to time in accordance with the bylaws of ICANN (as amended from time to time, the “ICANN Bylaws”) applicable to Consensus Policies (the “RSEP”). Registry Operator may offer Additional Services only with the written approval of ICANN, and, upon any such approval, such Additional Services shall be deemed Registry Services under this Agreement. In its reasonable discretion, ICANN may require an amendment to this Agreement reflecting the provision of any Additional Service which is approved pursuant to the RSEP, which amendment shall be in a form reasonably acceptable to the parties.
2. Section 2.2 is hereby amended and restated in its entirety as follows:
2.2 Compliance with Consensus Policies and Temporary Policies. Registry Operator shall comply with and implement all Consensus Policies and Temporary Policies found at https://www.icann.org/consensus-policies, as of the Effective Date and as may in the future be developed and adopted in accordance with the ICANN Bylaws, provided such future Consensus Polices and Temporary Policies are adopted in accordance with the procedure and relate to those topics and subject to those limitations set forth in Specification 1 attached hereto (“Specification 1”).
3. Section 2.9(a) is hereby amended and restated in its entirety as follows:
(a) All domain name registrations in the TLD must be registered through an ICANN accredited registrar; provided, that Registry Operator need not use a registrar if it registers names in its own name in order to withhold such names from delegation or use in accordance with Section 2.6. Subject to the requirements of Specification 11, Registry Operator must provide non-discriminatory access to Registry Services to all ICANN accredited registrars that enter into and are in compliance with the registry-registrar agreement for the TLD; provided that Registry Operator may establish non-discriminatory criteria for qualification to register names in the TLD that are reasonably related to the proper functioning of the TLD. Registry Operator must use a uniform non-discriminatory agreement with all registrars authorized to register names in the TLD (the “Registry-Registrar Agreement”). Registry Operator may amend the Registry-Registrar Agreement from time to time; provided, however, that any material revisions thereto must be approved by ICANN before any such revisions become effective and binding on any registrar. Registry Operator will provide ICANN and all registrars authorized to register names in the TLD at least fifteen (15) calendar days written notice of any revisions to the Registry-Registrar Agreement before any such revisions become effective and binding on any registrar. During such period, ICANN will determine whether such proposed revisions are immaterial, potentially material or material in nature. If ICANN has not provided Registry Operator with notice of its determination within such fifteen (15) calendar-day period, ICANN shall be deemed to have determined that such proposed revisions are immaterial in nature. If ICANN determines, or is deemed to have determined under this Section 2.9(a), that such revisions are immaterial, then Registry Operator may adopt and implement such revisions. If ICANN determines such revisions are either material or potentially material, ICANN will thereafter follow its procedure regarding review and approval of changes to Registry-Registrar Agreements at https://www.icann.org/rra-amendment-procedure, and such revisions may not be adopted and implemented until approved by ICANN. Notwithstanding the foregoing provisions of this Section 2.9(a), any change to the Registry-Registrar Agreement that relates exclusively to the fee charged by Registry Operator to register domain names in the TLD will not be subject to the notice and approval process specified in this Section 2.9(a), but will be subject to the requirements in Section 2.10 below.
4. Section 2.13 is hereby amended and restated in its entirety as follows:
2.13 Emergency Transition. Registry Operator agrees that, in the event that any of the emergency thresholds for registry functions set forth in Section 6 of Specification 10 is reached, ICANN may designate an emergency interim registry operator of the registry for the TLD (an “Emergency Operator”) in accordance with ICANN’s registry transition process (available at https://www.icann.org/registry-transition-processes) (as the same may be amended from time to time, the “Registry Transition Process”) until such time as Registry Operator has demonstrated to ICANN’s reasonable satisfaction that it can resume operation of the registry for the TLD without the reoccurrence of such failure. Following such demonstration, Registry Operator may transition back into operation of the registry for the TLD pursuant to the procedures set out in the Registry Transition Process, provided that Registry Operator pays all reasonable costs incurred (i) by ICANN as a result of the designation of the Emergency Operator and (ii) by the Emergency Operator in connection with the operation of the registry for the TLD, which costs shall be documented in reasonable detail in records that shall be made available to Registry Operator. In the event ICANN designates an Emergency Operator pursuant to this Section 2.13 and the Registry Transition Process, Registry Operator shall provide ICANN or any such Emergency Operator with all data (including the data escrowed in accordance with Section 2.3) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such Emergency Operator. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database with respect to the TLD in the event that an Emergency Operator is designated pursuant to this Section 2.13. In addition, in the event of such failure, ICANN shall retain and may enforce its rights under the Continued Operations Instrument.
5. If the Applicable Registry Agreement is for a Community-Based TLD as was determined by ICANN at the time of execution of the Applicable Registry Agreement, Section 2.19 is hereby amended and restated in its entirety as follows:
2.19 Obligations of Registry Operator to TLD Community. Registry Operator shall establish registration policies in conformity with the application submitted with respect to the TLD for: (i) naming conventions within the TLD, (ii) requirements for registration by members of the TLD community, and (iii) use of registered domain names in conformity with the stated purpose of the community-based TLD. Registry Operator shall operate the TLD in a manner that allows the TLD community to discuss and participate in the development and modification of policies and practices for the TLD. Registry Operator shall establish procedures for the enforcement of registration policies for the TLD, and resolution of disputes concerning compliance with TLD registration policies, and shall enforce such registration policies. Registry Operator agrees to implement and be bound by the Registry Restrictions Dispute Resolution Procedure as set forth at https://www.icann.org/rrdrp with respect to disputes arising pursuant to this Section 2.19. Registry Operator shall implement and comply with the community registration policies set forth on Specification 12 attached hereto.
6. Section 3.3 is hereby amended and restated in its entirety as follows:
3.3 TLD Nameservers. ICANN will use commercially reasonable efforts to ensure that any changes to the TLD nameserver designations submitted to ICANN by Registry Operator (in a format and with required technical elements specified by ICANN at https://www.iana.org/domains/root/ will be implemented by ICANN within seven (7) calendar days or as promptly as feasible following technical verifications.
7. Section 3.4 is hereby amended and restated in its entirety as follows:
3.4 Root-zone Information Publication. ICANN’s publication of root-zone contact information for the TLD will include Registry Operator and its administrative and technical contacts. Any request to modify the contact information for the Registry Operator must be made in the format specified from time to time by ICANN at https://www.iana.org/domains/root/.
8. Unless the Applicable Registry Operator was determined by ICANN at the time of execution of an Applicable Registry Agreement to be an intergovernmental organization or governmental entity or other special circumstances entity, Section
4.5 is hereby amended and restated in its entirety as follows:
4.5 Transition of Registry upon Termination of Agreement. Upon expiration of the Term pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement pursuant to Section 4.3 or Section 4.4, Registry Operator shall provide ICANN or any successor registry operator that may be designated by ICANN for the TLD in accordance with this Section 4.5 with all data (including the data escrowed in accordance with Section 2.3) regarding operations of the registry for the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such successor registry operator. After consultation with Registry Operator, ICANN shall determine whether or not to transition operation of the TLD to a successor registry operator in its sole discretion and in conformance with the Registry Transition Process; provided, however, that (i) ICANN will take into consideration any intellectual property rights of Registry Operator (as communicated to ICANN by Registry Operator) in determining whether to transition operation of the TLD to a successor registry operator and (ii) if Registry Operator demonstrates to ICANN’s reasonable satisfaction that (A) all domain name registrations in the TLD are registered to, and maintained by, Registry Operator or its Affiliates for their exclusive use, (B) Registry Operator does not sell, distribute or transfer control or use of any registrations in the TLD to any third party that is not an Affiliate of Registry Operator, and (C) transitioning operation of the TLD is not necessary to protect the public interest, then ICANN may not transition operation of the TLD to a successor registry operator upon the expiration or termination of this Agreement without the consent of Registry Operator (which shall not be unreasonably withheld, conditioned or delayed). For the avoidance of doubt, the foregoing sentence shall not prohibit ICANN from delegating the TLD pursuant to a future application process for the delegation of top-level domains, subject to any processes and objection procedures instituted by ICANN in connection with such application process intended to protect the rights of third parties. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database with respect to the TLD in the event of a transition of the TLD pursuant to this Section 4.5. In addition, ICANN or its designee shall retain and may enforce its rights under the Continued Operations Instrument for the maintenance and operation of the TLD, regardless of the reason for termination or expiration of this Agreement.
9. If the Applicable Registry Operator was determined by ICANN at the time of execution of an Applicable Registry Agreement to be an intergovernmental organization or governmental entity or other special circumstances entity, Section 4.5 is hereby amended and restated in its entirety as follows:
4.5 Transition of Registry upon Termination of Agreement. Upon expiration of the Term pursuant to Section 4.1 or Section 4.2 or any termination of this Agreement pursuant to Section 4.3 or Section 4.4, in connection with ICANN’s designation of a successor registry operator for the TLD, Registry Operator and ICANN agree to consult each other and work cooperatively to facilitate and implement the transition of the TLD in accordance with this Section 4.5. After consultation with Registry Operator, ICANN shall determine whether or not to transition operation of the TLD to a successor registry operator in its sole discretion and in conformance with the Registry Transition Process. In the event ICANN determines to transition operation of the TLD to a successor registry operator, upon Registry Operator’s consent (which shall not be unreasonably withheld, conditioned or delayed), Registry Operator shall provide ICANN or such successor registry operator for the TLD with any data regarding operations of the TLD necessary to maintain operations and registry functions that may be reasonably requested by ICANN or such successor registry operator in addition to data escrowed in accordance with Section 2.3 hereof. In the event that Registry Operator does not consent to provide such data, any registry data related to the TLD shall be returned to Registry Operator, unless otherwise agreed upon by the parties. Registry Operator agrees that ICANN may make any changes it deems necessary to the IANA database with respect to the TLD in the event of a transition of the TLD pursuant to this Section 4.5. In addition, ICANN or its designee shall retain and may enforce its rights under the Continued Operations Instrument, regardless of the reason for termination or expiration of this Agreement.
10. Section 6.2 is hereby amended and restated in its entirety as follows:
6.2 Cost Recovery for RSTEP. Requests by Registry Operator for the approval of Additional Services pursuant to Section 2.1 may be referred by ICANN to the Registry Services Technical Evaluation Panel (“RSTEP”) pursuant to that process at https://www.icann.org/rsep. In the event that such requests are referred to RSTEP, Registry Operator shall remit to ICANN the invoiced cost of the RSTEP review within fourteen (14) calendar days of receipt of a copy of the RSTEP invoice from ICANN, unless ICANN determines, in its sole and absolute discretion, to pay all or any portion of the invoiced cost of such RSTEP review.
11. Section 7.9 is hereby amended and restated in its entirety as follows; provided, however, that the notice information for each of the Applicable Registry Operators shall remain as set forth in each of the Appliable Registry Agreements or as updated pursuant to the terms of Section 7.9:
7.9 General Notices. Except for notices pursuant to Sections 7.6 and 7.7, all notices to be given under or in relation to this Agreement will be given either (i) in writing at the address of the appropriate party as set forth below or (ii) via electronic mail as provided below, unless that party has given a notice of change of postal or email address, as provided in this Agreement. All notices under Sections 7.6 and 7.7 shall be given by both posting of the applicable information on ICANN’s web site and transmission of such information to Registry Operator by electronic mail. Any change in the contact information for notice below will be given by the party within thirty (30) calendar days of such change. Other than notices under Sections 7.6 or 7.7, any notice required by this Agreement will be deemed to have been properly given (i) if in paper form, when delivered in person or via courier service with confirmation of receipt or (ii) by electronic mail, upon confirmation of receipt by the recipient’s email server, provided that such notice via electronic mail shall be followed by a copy sent by regular postal mail service within three (3) calendar days. Any notice required by Sections 7.6 or 7.7 will be deemed to have been given when electronically posted on ICANN’s website and upon confirmation of receipt by the email server. In the event other means of notice become practically achievable, such as notice via a secure website, the parties will work together to implement such notice means under this Agreement.
If
to ICANN, addressed to:
Internet Corporation for Assigned Names and Numbers
12025 Waterfront Drive, Suite 300
Los Angeles, CA 90094-2536
USA
Telephone: +1-310-301-5800
Attention: President and CEO
With
a Required Copy to: General Counsel
Email: (As specified from time to time.)
12. Section 7.13 is hereby amended and restated in its entirety as follows:
7.13 Severability; Conflicts with Laws. This Agreement shall be deemed severable; the invalidity or unenforceability of any term or provision of this Agreement shall not affect the validity or enforceability of the balance of this Agreement or of any other term hereof, which shall remain in full force and effect. If any of the provisions hereof are determined to be invalid or unenforceable, the parties shall negotiate in good faith to modify this Agreement so as to effect the original intent of the parties as closely as possible. ICANN and the Working Group will mutually cooperate to develop an ICANN procedure for ICANN’s review and consideration of alleged conflicts between applicable laws and non-RDDS (as defined in Specification 4) related provisions of this Agreement. Until such procedure is developed and implemented by ICANN, ICANN will review and consider alleged conflicts between applicable laws and non-RDDS related provisions of this Agreement in a manner similar to ICANN’s Procedure For Handling WHOIS Conflicts with Privacy Law.
13. The introductory paragraph of Exhibit A is hereby amended and restated in its entirety as follows:
The ICANN gTLD Applicant Guidebook (located at https://newgtlds.icann.org/en/applicants/agb) and the RSEP specify processes for consideration of proposed registry services. Registry Operator may provide any service that is required by the terms of this Agreement. In addition, the following services (if any) are specifically identified as having been approved by ICANN prior to the effective date of the Agreement, and Registry Operator may provide such services:
14. Section 3.1 of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
3.1 Deposit’s Format. Registry objects, such as domains, contacts, name servers, registrars, etc. will be compiled into a file constructed as described in RFC 8909, see Part A, Section 9, reference 1 of this Specification and RFC 9022, see Part A, Section 9, reference 2 of this Specification (collectively, the “DNDE Specification”). The DNDE Specification describes some elements as optional; Registry Operator will include those elements in the Deposits if they are available. UTF-8 character encoding will be used.
15. Section 9 of Part A of Specification 2 is hereby amended and restated in its entirety as follows:
(1) Registry Data Escrow Specification https://www.rfc-editor.org/rfc/rfc8909.txt
(2) Domain Name Registration Data (DNRD) Objects Mapping, https://www.rfc-editor.org/rfc/rfc9022.txt
(3) OpenPGP Message Format, https://www.rfc-editor.org/rfc/rfc4880.txt
(4) OpenPGP parameters, https://www.iana.org/assignments/pgp‑parameters/pgp‑parameters.xhtml
(5) ICANN Registry Interfaces, https://datatracker.ietf.org/doc/draft-lozano-icann-registry-interfaces
16. Field # 02 of Section 1 of Specification 3 is hereby amended and restated in its entirety as follows:
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 (as described in Specification 5), otherwise the sponsoring Registrar IANA id should be used as specified in https://www.iana.org/assignments/registrar-ids |
17. Fields # 03, 04 and 05 of Section 2 of Specification 3 are hereby amended and restated in their entirety as follows:
03 |
whois-43-queries |
number of WHOIS (port-43) queries responded during the reporting period; an empty value shall be used after the WHOIS Services Sunset Date (as defined in Specification 4) if the WHOIS (port 43) service is not provided after such date |
04 |
web-whois-queries |
number of web-based WHOIS queries responded during the reporting period, not including searchable WHOIS; an empty value shall be used after the WHOIS Services Sunset Date if the web-based WHOIS service is not provided after such date |
05 |
searchable-whois-queries |
number of searchable WHOIS queries responded during the reporting period; an empty value shall be used if searchable WHOIS service is not provided during the reporting period |
18. A new Field # 38 of Section 2 of Specification 3 is hereby added as follows:
38 |
rdap-queries |
number of RDAP queries responded during the reporting period |
19. The last paragraph of Section 2 of Specification 3 is hereby amended and restated in its entirety as follows:
For gTLDs that are part of a single-instance Shared Registry System: (1) the fields whois-43-queries, web-whois-queries, searchable-whois-queries and rdap-queries in the Registry Functions Activity Report should match the sum of queries reported for the gTLDs in the single-instance Shared Registry System, (2) in case of queries related to the fields in (1) above for which the Registry Operator cannot determine the TLD to count the query to (e.g., a registrar lookup query for a registrar operating in more than one TLD sharing the same RDAP base URL), registries have the flexibility to choose how to allocate those queries across the gTLDs utilizing the single-instance Shared Registry System, and (3) the Registry Functions Activity Report may include the total contact or host transactions for all the gTLDs in the system.
20. Section 1 of Specification 4 is hereby deleted in its entirety and replaced with the following:
1. Registration Data Directory Services
1.1. Definitions.
1.1.1 “Registration Data Access Protocol” or “RDAP” is an Internet protocol that provides “RESTful” web services to retrieve registration metadata from Domain Name Registries and Regional Internet Registries.
1.1.2 “RDAP Directory Services” refers to a Registration Data Directory Service using the RDAP described in STD 95 (https://www.rfc-editor.org/refs/ref-std95.txt), and its successor standards.
1.1.3 “Registration Data Directory Services” or “RDDS” refers to the collective of WHOIS Data Directory Services (as defined in this Specification 4) and Registration Data Access Protocol (RDAP) Directory Services (as defined in this Specification 4)."
1.1.4 “WHOIS Data Directory Services” refers to the collective of WHOIS service available via port 43 in accordance with RFC 3912 and a web-based WHOIS service providing free public query-based access to registration data.
1.1.5 “RDAP Ramp-Up Period” means the period that ends 3 February 2024.
1.1.6 “WHOIS Services Sunset Date” means the date that is 360 days after the expiration of the RDAP Ramp-Up Period, provided that ICANN and the Registries Stakeholder Group may mutually agree to postpone the WHOIS Services Sunset Date. If either the Chief Executive Officer of ICANN (“CEO”) or the Chairperson of the Registries Stakeholder Group (“Chair”) desires to discuss postponing the WHOIS Services Sunset Date, the CEO or Chair, as applicable, shall provide written notice to the other person, which shall set forth in reasonable detail the proposed postponement.
1.2. RDAP Directory Services
1.2.1 Registry Operator shall implement the most recent version of the RDAP Technical Implementation Guide and RDAP Response Profile posted at https://icann.org/gtld-rdap-profile. Registry Operator will implement new versions of the RDAP Technical Implementation Guide and RDAP Response Profile no later than one hundred eighty (180) calendar days after notification from ICANN.
1.2.2 Registry Operator shall provide lookup query support for:
(1) domain information as described in the section “Domain Path Segment Specification” of RFC 9082.
(2) nameserver information as described in the section “Nameserver Path Segment Specification” of RFC 9082; provided, however, that Registry Operator shall not be required to (but may still choose to) support nameserver lookup if Registry Operator specifies name servers as domain attributes in EPP.
(3) registrar information as described in the section “Entity Path Segment Specification” of RFC 9082.
(4) help information as described in the section "Help Path Segment Specification" of RFC 9082.
1.2.3 ICANN reserves the right to specify alternative formats and protocols approved as “Internet Standards” (as opposed to Informational or Experimental standards) through the applicable IETF processes with respect to Registration Data. Upon such specification, ICANN shall: (a) work collaboratively with gTLD registries and ICANN-accredited registrars to define all operational requirements necessary to implement the applicable standard; and (b) if applicable, initiate negotiations to define all reporting requirements (if any), and reasonable service level requirements commensurate with similarly situated services.
1.3. Searchability. Offering searchability capabilities for the Registration Data is optional but if offered by the Registry Operator it shall comply with the specification described in this section.
1.3.1 Registry Operator will offer searchability as a web-based service.
1.3.2 Registry Operator will offer partial match capabilities, on each of the following fields: domain name, contacts and registrant’s name, and contact and registrant’s postal address, including all the sub-fields described in EPP (e.g., street, city, state or province, etc.), and may offer partial match capabilities on other fields, in each case subject to applicable law.
1.3.3 Registry Operator will offer exact-match capabilities, at least, on the following fields: Registrar ID, name server name, and name server’s IP address (only applies to IP addresses stored by the registry, i.e., glue records).
1.3.4 Registry Operator will offer Boolean search capabilities supporting, at least, the following logical operators to join a set of search criteria: AND, OR, NOT.
1.3.5 Search results will include domain names matching the search criteria.
1.3.6 Registry Operator will: 1) implement appropriate measures to avoid abuse of this feature (e.g., permitting access only to legitimate authorized users); and 2) ensure the feature is in compliance with any applicable privacy laws and ICANN Consensus Policies and Temporary Policies.
1.3.7 Registry Operator shall only offer the searchability capabilities required in the RDAP Technical Implementation Guide and RDAP Response Profile in the RDAP Directory Services.
1.4. WHOIS Data Directory Services.
1.4.1 Until the WHOIS Services Sunset Date, Registry Operator will operate a WHOIS service available via port 43 in accordance with RFC 3912, and a web-based WHOIS Service at <whois.nic.TLD> providing free public query-based access to at least the following elements in the following format.
1.4.2 The format of responses shall follow a semi-free text format outlined below, followed by a blank line and a legal disclaimer specifying the rights of Registry Operator, and of the user querying the database.
1.4.3 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.4.4 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.5 The fields specified below set forth the minimum output requirements.
1.4.6 Domain Name Data
(1) Query format: whois EXAMPLE.TLD
(2) Response format:
Domain
Name: EXAMPLE.TLD
Registry Domain ID: D1234567-TLD
Registrar WHOIS Server: whois.example.tld
Registrar URL: http://www.example.tld
Updated Date: 2009-05-29T20:13:00Z
Creation Date: 2000-10-08T00:45:00Z
Registry Expiry Date: 2010-10-08T00:44:59Z
Registrar Registration Expiration Date:
2010-10-08T00:44:59Z[1]
Registrar: EXAMPLE REGISTRAR LLC
Registrar IANA ID: 5555555
Registrar Abuse Contact Email: email@registrar.tld
Registrar Abuse Contact Phone: +1.123551234
Reseller: EXAMPLE RESELLER1[2]
Domain Status: clientDeleteProhibited
Domain Status: clientRenewProhibited
Domain Status: clientTransferProhibited
Domain Status: serverUpdateProhibited
Registry Registrant ID: 5372808-ERL
Registrant Name: EXAMPLE REGISTRANT
Registrant Organization: EXAMPLE ORGANIZATION
Registrant Street: 123 EXAMPLE STREET
Registrant City: ANYTOWN
Registrant State/Province: AP
Registrant Postal Code: A1A1A1
Registrant Country: EX
Registrant Phone: +1.5555551212
Registrant Phone Ext: 1234
Registrant Fax: +1.5555551213
Registrant Fax Ext: 4321
Registrant Email: EMAIL@EXAMPLE.TLD
Registry Admin ID: 5372809-ERL
Admin Name: EXAMPLE REGISTRANT ADMINISTRATIVE
Admin Organization: EXAMPLE REGISTRANT ORGANIZATION
Admin Street: 123 EXAMPLE STREET
Admin City: ANYTOWN
Admin State/Province: AP
Admin Postal Code: A1A1A1
Admin Country: EX
Admin Phone: +1.5555551212
Admin Phone Ext: 1234
Admin Fax: +1.5555551213
Admin Fax Ext:
Admin Email: EMAIL@EXAMPLE.TLD
Registry Tech ID: 5372811-ERL
Tech Name: EXAMPLE REGISTRAR TECHNICAL
Tech Organization: EXAMPLE REGISTRAR LLC
Tech Street: 123 EXAMPLE STREET
Tech City: ANYTOWN
Tech State/Province: AP
Tech Postal Code: A1A1A1
Tech Country: EX
Tech Phone: +1.1235551234
Tech Phone Ext: 1234
Tech Fax: +1.5555551213
Tech Fax Ext: 93
Tech Email: EMAIL@EXAMPLE.TLD
Name Server: NS01.EXAMPLEREGISTRAR.TLD
Name Server: NS02.EXAMPLEREGISTRAR.TLD
DNSSEC: signedDelegation
DNSSEC: unsigned
URL of the ICANN WHOIS Inaccuracy Complaint Form:
https://www.icann.org/wicf/
>>> Last update of WHOIS
database: 2009-05-29T20:15:00Z <<<
1.4.7 Registrar Data
(1) Query format: whois “registrar Example Registrar, Inc.”
(2) Response format:
Registrar: Example Registrar, Inc.
Street: 1234 Admiralty Way
City: Marina del Rey
State/Province: CA
Postal Code: 90292
Country: US
Phone Number: +1.3105551212
Fax Number: +1.3105551213
Email: registrar@example.tld
Registrar WHOIS Server:
whois.example-registrar.tld
Registrar URL: http://www.example-registrar.tld
Admin Contact: Joe Registrar
Phone Number: +1.3105551213
Fax Number: +1.3105551213
Email: joeregistrar@example-registrar.tld
Admin Contact: Jane Registrar
Phone Number: +1.3105551214
Fax Number: +1.3105551213
Email: janeregistrar@example-registrar.tld
Technical Contact: John Geek
Phone Number: +1.3105551215
Fax Number: +1.3105551216
Email: johngeek@example-registrar.tld
>>> Last update of WHOIS database: 2009-05-29T20:15:00Z <<<
1.4.8 Nameserver Data:
(1) Query format: whois “nameserver (nameserver name)”, or whois “nameserver (IP Address).” For example: whois “nameserver NS1.EXAMPLE.TLD”.
(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.4.9 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.5.4 Registry Operator must adhere to the requirements related to additional fields of the Consistent Labeling and Display Consensus Policy if they choose to add data fields.
1.7 Cooperation with Transition Studies. If ICANN initiates or commissions a study on the transition of WHOIS Data Directory Services to RDAP Directory Services, Registry Operator shall reasonably cooperate with such study, including by delivering to ICANN or its designee conducting such study, both quantitative and qualitative data related to its experience with its transition from WHOIS Data Directory Services to RDAP Data Directory Services. If the data request is beyond what the Registry Operator collects in the ordinary course of its operations and beyond the data that Registry Operator is required to collect and provide to ICANN org pursuant to this Agreement, Registry Operator should voluntarily cooperate to provide the requested information or provide an explanation to ICANN why the Registry Operator is not able to provide the requested information. The terms of this section do not require Registry Operator to provide data to ICANN that is beyond what Registry Operator is obligated to provide ICANN pursuant to other sections of this Agreement. Any data delivered to ICANN or its designee pursuant to this section that is appropriately marked as confidential pursuant to the confidentiality provisions of the Agreement shall be treated as Confidential Information of Registry Operator in accordance with the confidentiality provisions of the Agreement, provided that, notwithstanding the Agreement, if ICANN or its designee aggregates and makes anonymous such data, ICANN or its designee may disclose such data to any third party. Following completion of the transition study for which Registry Operator has provided data, ICANN will destroy all data provided by Registry Operator pursuant to this section that has not been aggregated and made anonymous.
1.8. Policy and Educational Materials. Registry Operator shall provide a link on the primary website for the TLD (i.e., the website provided to ICANN for publishing on the ICANN website) to a web page designated by ICANN containing RDDS policy and educational materials.
21. Section 2.1.1 of Specification 4 is hereby amended and restated in its entirety as follows:
2.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 2.1.3 of this Specification and do so using the file format described in Section 2.1.4 of this Specification. 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 2.1.2 of this Specification; (b) Registry Operator may reject the request for access of any user that does not provide correct or legitimate credentials under Section 2.1.2 of this Specification or where Registry Operator reasonably believes will violate the terms of Section 2.1.5. of this Specification; 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 2.1.5 of this Specification.
22. Section 3.1 of Specification 4 is hereby amended and restated in its entirety as follows:
3.1. Periodic Access to Thin Registration Data. In order to verify and ensure the operational stability of Registry Services, analyze the operational stability of the DNS, and facilitate compliance checks on accredited registrars, Registry Operator will provide ICANN on a weekly basis (the day to be designated by ICANN) with up-to-date Registration Data as specified below. Data will include data committed as of 00:00:00 UTC on the day previous to the one designated for retrieval by ICANN.
On an annual basis, ICANN will publish a summary of the research projects that utilized this data in the preceding year, along with a listing of any organizations the raw data was shared with to conduct the research.
23. Section 3.1.1 of Specification 4 is hereby amended and restated in its entirety as follows:
3.1.1 Contents. Registry Operator will provide the following data for all registered domain names: domain name, domain name repository object id (roid), Registrar ID (IANA ID), statuses, last updated date, creation date, expiration date, and name server names. For sponsoring registrars Registry Operator will provide: registrar name, registrar id (IANA ID), hostname of registrar WHOIS server (this data element may be omitted after the WHOIS Services Sunset Date), and URL of registrar. Registry Operator shall not provide any additional data elements.
24. Section 3.1.1 of Specification 5 is hereby amended and restated in its entirety as follows:
3.1.1 If Exhibit A to the Agreement specifically provides that Registry Operator may offer registration of IDNs, Registry Operator may also activate a language-specific translation or transliteration of the term "NIC" or an abbreviation for the translation of the term "Network Information Center" in the DNS in accordance with Registry Operator’s IDN Tables and IDN Registration Rules. Such translation, transliteration or abbreviation may be reserved by Registry Operator and used in addition to the label NIC to provide any required registry functions. For the avoidance of doubt, Registry Operator is required to activate the ASCII label NIC pursuant to Section 3.1 of this Specification 5.
25. Section 4.1 of Specification 5 is hereby amended and restated in its entirety as follows:
4.1. the short form (in English) of all country and territory names contained on the ISO 3166-1 list, as updated from time to time, including the European Union, which is exceptionally reserved on the ISO 3166-1 list, and its scope extended in August 1999 to any application needing to represent the name European Union https://www.iso.org/iso-3166-country-codes.html;
26. Section 5 of Specification 5 is hereby amended and restated in its entirety as follows:
5. International Olympic Committee; International Red Cross and Red Crescent Movement. As instructed from time to time by ICANN, the names (including their IDN variants, where applicable) relating to the International Olympic Committee, International Red Cross and Red Crescent Movement listed at https://www.icann.org/reserved-names shall be withheld from registration or allocated to Registry Operator at the second level within the TLD. Additional International Olympic Committee, International Red Cross and Red Crescent Movement names (including their IDN variants) may be added to the list upon ten (10) calendar days notice from ICANN to Registry Operator. Such names may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, all such names withheld from registration or allocated to Registry Operator shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement.
27. Section 6 of Specification 5 is hereby amended and restated in its entirety as follows:
6. Intergovernmental Organizations. As instructed from time to time by ICANN, Registry Operator will implement the protections mechanism determined by the ICANN Board of Directors relating to the protection of identifiers for Intergovernmental Organizations. A list of reserved names for this Section 6 is available at https://www.icann.org/reserved-names. Additional names (including their IDN variants) may be added to the list upon ten (10) calendar days notice from ICANN to Registry Operator. Any such protected identifiers for Intergovernmental Organizations may not be activated in the DNS, and may not be released for registration to any person or entity other than Registry Operator. Upon conclusion of Registry Operator’s designation as operator of the registry for the TLD, all such protected identifiers shall be transferred as specified by ICANN. Registry Operator may self-allocate and renew such names without use of an ICANN accredited registrar, which will not be considered Transactions for purposes of Section 6.1 of the Agreement.
28. Section 1.4 of Specification 6 is hereby amended and restated in its entirety as follows:
1.4. IDN. If the Registry Operator offers Internationalized Domain Names (“IDNs”), it shall comply with RFCs 5890, 5891, 5892, 5893 and their successors. Registry Operator shall comply with the ICANN IDN Guidelines at https://www.icann.org/en/topics/idn/implementation-guidelines.htm, as they may be amended, modified, or superseded from time to time. Registry Operator shall publish and keep updated its IDN Tables and IDN Registration Rules in the IANA Repository of IDN Practices.
29. Section 1.5 of Specification 6 is hereby amended and restated in its entirety as follows:
1.5. IPv6. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry’s name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow “DNS IPv6 Transport Operational Guidelines” as described in BCP 91 and the recommendations and considerations described in RFC 4472. Registry Operator shall offer in addition to IPv4 transport, public IPv6 transport for its Registration Data Directory Services as defined in Specification 4 of this Agreement; e.g., WHOIS (RFC 3912), web-based WHOIS, and RDAP. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six (6) months after receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS over IPv6.
30. Section 1.6 of Specification 6 is hereby amended and restated in its entirety as follows:
1.6. IANA Rootzone Database. In order to ensure that authoritative information about the TLD remains publicly available, Registry Operator shall submit a change request to the IANA functions operator updating any outdated or inaccurate DNS, WHOIS or RDAP base URL of the RDAP service records of the TLD. Registry Operator shall use commercially reasonable efforts to submit any such change request no later than seven (7) calendar days after the date any such DNS, WHOIS or RDAP base URL of the RDAP service records becomes outdated or inaccurate. Registry Operator must submit all change requests in accordance with the procedures set forth at https://www.iana.org/domains/root.
31. Section 4.2 of Specification 6 is hereby amended and restated in its entirety as follows:
4.2. Malicious Use of Orphan Glue Records. Registry Operator shall take action to remove orphan glue records (as defined at https://www.icann.org/en/committees/security/sac048.pdf) when provided with evidence in written form that such records are present in connection with malicious conduct.
32. Section 6.2.2 of Specification 6 is hereby amended and restated in its entirety as follows:
6.2.2 Notwithstanding subsection 6.2.1, Registry Operator may proceed with activation of names in the DNS zone without implementation of the measures set forth in Section 6.2.1 only if (A) ICANN determines that the Registry TLD is eligible for this alternative path to activation of names; and (B) Registry Operator blocks all second-level domain names identified by ICANN and set forth at https://newgtlds.icann.org/en/announcements-and-media/announcement-2-17nov13-en as such list may be modified by ICANN from time to time. Registry Operator may activate names pursuant to this subsection and later activate names pursuant to subsection 6.2.1.
33. Section 6.2.3 of Specification 6 is hereby amended and restated in its entirety as follows:
6.2.3 The sets of names subject to mitigation or blocking pursuant to Sections 6.2.1 and 6.2.2 will be based on ICANN analysis of DNS information including "Day in the Life of the Internet" data maintained by the DNS Operations, Analysis, and Research Center (DNS-OARC) https://www.dns-oarc.net/oarc/data/ditl.
34. Section 6.2.5 of Specification 6 is hereby amended and restated in its entirety as follows:
6.2.5 If ICANN determines that the TLD is ineligible for the alternative path to activation of names, ICANN may elect not to delegate the TLD pending completion of the final Name Collision Occurrence Assessment for the TLD, and Registry Operator’s completion of all required mitigation measures. Registry Operator understands that the mitigation measures required by ICANN as a condition to activation of names in the DNS zone for the TLD may include, without limitation, mitigation measures such as those described in Section 3.2 of the New gTLD Name Collision Occurrence Management Plan approved by the ICANN Board New gTLD Program Committee (NGPC) on 7 October 2013 as found at https://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-07oct13-en.pdf.
35. The first paragraph of Section 1 of Specification 7 is hereby amended and restated in its entirety as follows:
1. Rights Protection Mechanisms. Registry Operator shall implement and adhere to the rights protection mechanisms (“RPMs”) specified in this Specification. In addition to such RPMs, Registry Operator may develop and implement additional RPMs that discourage or prevent registration of domain names that violate or abuse another party’s legal rights. Registry Operator will include all RPMs required by this Specification 7 and any additional RPMs developed and implemented by Registry Operator in the Registry-Registrar Agreement entered into by ICANN-accredited registrars authorized to register names in the TLD. Registry Operator shall implement in accordance with requirements set forth therein each of the mandatory RPMs set forth in the Trademark Clearinghouse as of the date hereof, as posted at https://www.icann.org/en/resources/registries/tmch-requirements (the “Trademark Clearinghouse Requirements”), which may be revised in immaterial respects by ICANN from time to time. Registry Operator shall not mandate that any owner of applicable intellectual property rights use any other trademark information aggregation, notification, or validation service in addition to or instead of the ICANN-designated Trademark Clearinghouse. If there is a conflict between the terms and conditions of this Agreement and the Trademark Clearinghouse Requirements, the terms and conditions of this Agreement shall control. Registry Operator must enter into a binding and enforceable Registry-Registrar Agreement with at least one ICANN accredited registrar authorizing such registrar(s) to register domain names in the TLD as follows:
36. Section 2.a of Specification 7 is hereby amended and restated in its entirety as follows:
a. the Trademark Post-Delegation Dispute Resolution Procedure (PDDRP) and the Registration Restriction Dispute Resolution Procedure (RRDRP) adopted by ICANN (posted at https://www.icann.org/pddrp and https://www.icann.org/rrdrp, respectively). Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PDDRP or RRDRP panel and to be bound by any such determination; and
37. Section 2.b of Specification 7 is hereby amended and restated in its entirety as follows:
b. the Uniform Rapid Suspension system (“URS”) adopted by ICANN (posted at https://www.icann.org/urs), including the implementation of determinations issued by URS examiners.
38. Section 1.6 of Specification 10 is hereby deleted in its entirety and replaced with the following:
39. A new Section 1.9 of Specification 10 is hereby added as follows:
1.9. RDAP-RDDS. Refers to the Registration Data Access Protocol (RDAP) Directory Services as defined in Specification 4 of this Agreement.
40. A new Section 1.10 of Specification 10 is hereby added as follows:
1.10. WHOIS-RDDS and WHOIS Data Directory Services. Refers to the collective of WHOIS and web-based WHOIS services as defined in Specification 4 of this Agreement.
41. Section 2 of Specification 10 is hereby deleted in its entirety and replaced with the following:
2. Service Level Agreement Matrix
2.1. With respect to the TLD, Registry Operator shall meet or exceed each of the following SLRs related to the DNS, EPP and RDAP-RDDS* services:
*These SLRs for RDAP-RDDS are not mandatory until the expiration of the RDAP Ramp-Up Period.
2.2. Registry Operator is encouraged to do maintenance for the different services at the times and dates of statistically lower traffic for each service. However, note that there is no provision for planned outages or similar periods of unavailable or slow service; any downtime, be it for maintenance or due to system failures, will be noted simply as downtime and counted for SLR measurement purposes.
2.3. With respect to the TLD, until the WHOIS Services Sunset Date, Registry Operator shall meet or exceed each of the following SLRs related to the WHOIS Data Directory Services:
42. Section 3.2 of Specification 10 is hereby amended and restated in its entirety as follows:
3.2. DNS name server availability. Refers to the ability of a public-DNS registered “IP address” of a particular name server listed as authoritative for a domain name, to answer DNS queries from an Internet user. All the public DNS-registered “IP address” of all name servers of the domain name being monitored shall be tested individually. If 51% or more of the DNS testing probes get unanswered results from “DNS tests” to a name server “IP address” during a given time, the name server “IP address” will be considered unanswered.
43. Section 3.3 of Specification 10 is hereby amended and restated in its entirety as follows:
3.3. UDP DNS resolution RTT. Refers to the RTT of the sequence of two packets, the UDP DNS query and the corresponding UDP DNS response. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered unanswered.
44. Section 3.4 of Specification 10 is hereby amended and restated in its entirety as follows:
3.4. TCP DNS resolution RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the DNS response for only one DNS query. If the RTT is 5 times greater than the time specified in the relevant SLR, the RTT will be considered unanswered.
45. Section 3.7 of Specification 10 is hereby amended and restated in its entirety as follows:
3.7. DNS test. Means one non-recursive DNS query sent to a particular “IP address” (via UDP or TCP). If DNSSEC is offered in the queried DNS zone, for a query to be considered answered, the signatures must be positively verified against a corresponding DS record published in the parent zone or, if the parent is not signed, against a statically configured Trust Anchor. The answer to the query must contain the corresponding information from the Registry System, otherwise the query will be considered unanswered. A query with a “DNS resolution RTT” 5 times higher than the corresponding SLR, will be considered unanswered. The possible results to a DNS test are: a number in milliseconds corresponding to the “DNS resolution RTT” or, unanswered.
46. Section 3.8 of Specification 10 is hereby amended and restated in its entirety as follows:
3.8. Measuring DNS parameters. Every minute, every DNS probe will make an UDP or TCP “DNS test” to each of the public-DNS registered “IP addresses” of the name servers of the domain name being monitored. If a “DNS test” result is unanswered, the tested IP will be considered unavailable from that probe until it is time to make a new test.
47. Section 3.11 of Specification 10 is hereby amended and restated in its entirety as follows:
3.11. Placement of DNS probes. ICANN will use commercially reasonable efforts to deploy probes for measuring DNS parameters in data centers with carrier grade connectivity in each of the ICANN geographic regions.
48. Section 4 of Specification 10 is hereby deleted in its entirety and replaced with the following:
4.1. RDAP-RDDS
4.1.1 RDAP Availability. Refers to the ability of the RDAP-RDDS service for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the RDAP testing Probes see the RDAP-RDDS service as unavailable during a given time, the RDAP-RDDS service will be considered unanswered.
4.1.2 RDAP-query RTT. Refers to the RTT of the sequence of packets from the start of an RDAP-RDDS testing probe’s TCP connection to its end, including the reception of the HTTPS response for only one HTTPS request. If the RTT is 5 times or more the corresponding SLR/performance specifications, the RTT will be considered undefined.
4.1.3 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 RDAP-RDDS testing Probes detect the changes made.
4.1.4 RDAP test. Means one query sent to a particular IP address of one of the servers of the RDAP-RDDS service. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an RDAP test are: a number in milliseconds corresponding to the RDAP-query RTT or unanswered.
4.1.5 Measuring RDAP parameters. Every 5 minutes, RDAP-RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers of the RDAP-RDDS service of the TLD being monitored and make an “RDAP test”. If an RDAP test result is unanswered, the corresponding RDAP-RDDS service will be considered as unavailable from that Probe until it is time to make a new test.
4.1.6 Collating the results from RDAP-RDDS Probes. The minimum number of active testing working RDAP-RDDS testing Probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered “inconclusive”; during this situation no fault will be flagged against the SLRs.
4.1.7 Placement of RDAP-RDDS Probes. ICANN will use commercially reasonable efforts to deploy probes for measuring RDAP parameters in data centers with carrier grade connectivity in each of the ICANN geographic regions.
4.2. WHOIS-RDDS. Until the WHOIS Services Sunset Date, Registry Operator shall comply with the provisions of this Section 4.2.
4.2.1 WHOIS-RDDS availability. Refers to the ability of all the WHOIS-RDDS services for the TLD, to respond to queries from an Internet user with appropriate data from the relevant Registry System. If 51% or more of the WHOIS-RDDS testing probes see any of the WHOIS-RDDS services as unavailable during a given time, the WHOIS-RDDS will be considered unavailable.
4.2.2 WHOIS
query RTT. Refers to the RTT
of the sequence of packets from the start of the TCP connection to its end,
including the reception of the WHOIS response. If the RTT is 5 -times or more
the corresponding SLR, the RTT will be considered unanswered.
4.2.3 Web-based-WHOIS query RTT. Refers to the RTT of the sequence of packets from the start of the TCP connection to its end, including the reception of the HTTP response for only one HTTP request. If Registry Operator implements 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, the RTT will be considered unanswered.
4.2.4 WHOIS-RDDS query RTT. Refers to the collective of “WHOIS query RTT” and “Web-based- WHOIS query RTT”.
4.2.5 WHOIS-RDDS update time. Refers to the time measured from the reception of an EPP confirmation to a transform command on a domain name, host or contact, up until the servers of the WHOIS-RDDS services reflect the changes made.
4.2.6 WHOIS-RDDS test. Means one query sent to a particular “IP address” of one of the servers of one of the WHOIS-RDDS services. Queries shall be about existing objects in the Registry System and the responses must contain the corresponding information otherwise the query will be considered unanswered. Queries with an RTT 5 times higher than the corresponding SLR will be considered as unanswered. The possible results to an WHOIS-RDDS test are: a number in milliseconds corresponding to the RTT or unanswered.
4.2.7 Measuring WHOIS-RDDS parameters. Every 5 minutes, WHOIS-RDDS probes will select one IP address from all the public-DNS registered “IP addresses” of the servers for each WHOIS-RDDS service of the TLD being monitored and make an “WHOIS-RDDS test” to each one. If an “WHOIS-RDDS test” result is unanswered, the corresponding WHOIS-RDDS service will be considered as unavailable from that probe until it is time to make a new test.
4.2.8 Collating the results from WHOIS-RDDS probes. The minimum number of active testing probes to consider a measurement valid is 10 at any given measurement period, otherwise the measurements will be discarded and will be considered inconclusive; during this situation no fault will be flagged against the SLRs.
4.2.9 Placement of WHOIS-RDDS probes. ICANN will use commercially reasonable efforts to deploy probes for measuring WHOIS-RDDS parameters in data centers with carrier grade connectivity in each of the ICANN geographic regions.
49. Section 5.2 of Specification 10 is hereby amended and restated in its entirety as follows:
5.2. EPP session-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a session command plus the reception of the EPP response for only one EPP session command. For the login command it will include packets needed for starting the TCP session. For the logout command it will include packets needed for closing the TCP session. EPP session commands are those described in section 2.9.1 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered unanswered.
50. Section 5.3 of Specification 10 is hereby amended and restated in its entirety as follows:
5.3. EPP query-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a query command plus the reception of the EPP response for only one EPP query command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP query commands are those described in section 2.9.2 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered unanswered.
51. Section 5.4 of Specification 10 is hereby amended and restated in its entirety as follows:
5.4. EPP transform-command RTT. Refers to the RTT of the sequence of packets that includes the sending of a transform command plus the reception of the EPP response for only one EPP transform command. It does not include packets needed for the start or close of either the EPP or the TCP session. EPP transform commands are those described in section 2.9.3 of EPP RFC 5730. If the RTT is 5 times or more the corresponding SLR, the RTT will be considered unanswered.
52. Section 5.6 of Specification 10 is hereby amended and restated in its entirety as follows:
5.6. EPP test. Means one EPP command sent to a particular “IP address” for one of the EPP servers. Query and transform commands, with the exception of “create”, shall be about existing objects in the Registry System. The response shall include appropriate data from the Registry System. The possible results to an EPP test are: a number in milliseconds corresponding to the “EPP command RTT” or unanswered.
53. Section 5.7 of Specification 10 is hereby amended and restated in its entirety as follows:
5.7. Measuring EPP parameters. Every 5 minutes, EPP probes will select one “IP address” of the EPP servers of the TLD being monitored and make an “EPP test”; every time they should alternate between the 3 different types of commands and between the commands inside each category. If an “EPP test” result is unanswered, the EPP service will be considered as unavailable from that probe until it is time to make a new test.
54. Section 5.9 of Specification 10 is hereby amended and restated in its entirety as follows:
5.9. Placement of EPP probes. ICANN will use commercially reasonable efforts to deploy probes for measuring EPP parameters in data centers with carrier-grade connectivity and close to Registrar points of access to the Internet in each ICANN geographic region.
55. Section 6 of Specification 10 is hereby deleted in its entirety and replaced with the following:
6.1. The following matrix presents the emergency thresholds that, if reached by any of the services related to DNS, EPP, RDAP-RDDS* and Data Escrow for a TLD, would cause the emergency transition of the Registry for the TLD as specified in Section 2.13 of this Agreement.
Critical Function |
Emergency Threshold |
DNS Service |
4-hour total downtime / week |
DNSSEC proper resolution |
4-hour total downtime / week |
EPP |
24-hour total downtime / week |
24-hour total downtime / week |
|
Data Escrow |
Reaching any of the criteria for the release of deposits described in Specification 2, Part B, Section 6.2 through Section 6.6. |
*The RDAP-RDDS emergency threshold becomes effective upon expiration of the RDAP Ramp-Up Period.
6.2. The following matrix presents the emergency thresholds that, if reached by any of the services related to WHOIS-RDDS for a TLD prior to the expiration of the RDAP Ramp-Up Period would cause the emergency transition of the Registry for the TLD as specified in Section 2.13 of this Agreement.
Emergency Threshold |
|
WHOIS-RDDS |
24-hour total downtime / week |
56. The first paragraph of Section 2 of Specification 11 is hereby amended and restated in its entirety as follows:
2. Registry Operator will operate the registry for the TLD in compliance with all commitments, statements of intent and business plans stated in the following sections of Registry Operator’s application to ICANN for the TLD, which commitments, statements of intent and business plans are hereby incorporated by reference into this Agreement. Registry Operator’s obligations pursuant to this paragraph shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN (posted at https://www.icann.org/picdrp), which may be revised in immaterial respects by ICANN from time to time (the “PICDRP”). Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination
57. The first paragraph of Section 3 of Specification 11 is hereby amended and restated in its entirety as follows:
3. Registry Operator agrees to perform the following specific public interest commitments, which commitments shall be enforceable by ICANN and through the Public Interest Commitment Dispute Resolution Process established by ICANN (posted at https://www.icann.org/picdrp), which may be revised in immaterial respects by ICANN from time to time (the “PICDRP”). Registry Operator shall comply with the PICDRP. Registry Operator agrees to implement and adhere to any remedies ICANN imposes (which may include any reasonable remedy, including for the avoidance of doubt, the termination of the Registry Agreement pursuant to Section 4.3(e) of the Agreement) following a determination by any PICDRP panel and to be bound by any such determination.
aaa |
ally |
author |
aarp |
alsace |
auto |
abarth |
alstom |
autos |
abb |
amazon |
avianca |
abbott |
americanexpress |
aws |
abbvie |
americanfamily |
axa |
abc |
amex |
azure |
able |
amfam |
baby |
abogado |
amica |
baidu |
abudhabi |
amsterdam |
banamex |
academy |
analytics |
bananarepublic |
accenture |
android |
band |
accountant |
anquan |
bank |
accountants |
anz |
bar |
aco |
aol |
barcelona |
actor |
apartments |
barclaycard |
ads |
app |
barclays |
adult |
apple |
barefoot |
aeg |
aquarelle |
bargains |
aero |
arab |
baseball |
aetna |
aramco |
basketball |
afl |
archi |
bauhaus |
africa |
army |
bayern |
agakhan |
art |
bbc |
agency |
arte |
bbt |
aig |
asda |
bbva |
airbus |
asia |
bcg |
airforce |
associates |
bcn |
airtel |
athleta |
beats |
akdn |
attorney |
beauty |
alfaromeo |
auction |
beer |
alibaba |
audi |
bentley |
alipay |
audible |
berlin |
allfinanz |
audio |
best |
allstate |
auspost |
bestbuy |
bet |
builders |
cfd |
bharti |
business |
chanel |
bible |
buy |
channel |
bid |
buzz |
charity |
bike |
bzh |
chase |
bing |
cab |
chat |
bingo |
cafe |
cheap |
bio |
cal |
chintai |
biz |
call |
christmas |
black |
calvinklein |
chrome |
blackfriday |
cam |
church |
blockbuster |
camera |
cipriani |
blog |
camp |
circle |
bloomberg |
canon |
cisco |
blue |
capetown |
citadel |
bms |
capital |
citi |
bmw |
capitalone |
citic |
bnpparibas |
car |
city |
boats |
caravan |
cityeats |
boehringer |
cards |
claims |
bofa |
care |
cleaning |
bom |
career |
click |
bond |
careers |
clinic |
boo |
cars |
clinique |
book |
casa |
clothing |
booking |
case |
cloud |
bosch |
cash |
club |
bostik |
casino |
clubmed |
boston |
cat |
coach |
bot |
catering |
codes |
boutique |
catholic |
coffee |
box |
cba |
college |
bradesco |
cbn |
cologne |
bridgestone |
cbre |
comcast |
broadway |
cbs |
commbank |
broker |
center |
community |
brother |
ceo |
company |
brussels |
cern |
compare |
build |
cfa |
computer |
comsec |
degree |
edeka |
condos |
delivery |
education |
construction |
dell |
|
consulting |
deloitte |
emerck |
contact |
delta |
energy |
contractors |
democrat |
engineer |
cooking |
dental |
engineering |
cookingchannel |
dentist |
enterprises |
cool |
desi |
epson |
corsica |
design |
equipment |
country |
dev |
ericsson |
coupon |
dhl |
erni |
coupons |
diamonds |
esq |
courses |
diet |
estate |
cpa |
digital |
etisalat |
credit |
direct |
eurovision |
creditcard |
directory |
eus |
creditunion |
discount |
events |
cricket |
discover |
exchange |
crown |
dish |
expert |
crs |
diy |
exposed |
cruise |
dnp |
express |
cruises |
docs |
extraspace |
cuisinella |
doctor |
fage |
cymru |
dog |
fail |
cyou |
domains |
fairwinds |
dabur |
dot |
faith |
dad |
download |
family |
dance |
drive |
fan |
data |
dtv |
fans |
date |
dubai |
farm |
dating |
dunlop |
farmers |
datsun |
dupont |
fashion |
day |
durban |
fast |
dclk |
dvag |
fedex |
dds |
dvr |
feedback |
deal |
earth |
ferrari |
dealer |
eat |
ferrero |
deals |
eco |
fiat |
fidelity |
furniture |
gop |
fido |
futbol |
got |
film |
fyi |
grainger |
final |
gal |
graphics |
finance |
gallery |
gratis |
financial |
gallo |
green |
fire |
gallup |
gripe |
firestone |
game |
grocery |
firmdale |
games |
group |
fish |
gap |
guardian |
fishing |
garden |
gucci |
fit |
gay |
guge |
fitness |
gbiz |
guide |
flickr |
gdn |
guitars |
flights |
gea |
guru |
flir |
gent |
hair |
florist |
genting |
hamburg |
flowers |
george |
hangout |
fly |
ggee |
haus |
foo |
gift |
hbo |
food |
gifts |
hdfc |
foodnetwork |
gives |
hdfcbank |
football |
giving |
health |
ford |
glass |
healthcare |
forex |
gle |
help |
forsale |
global |
helsinki |
forum |
globo |
here |
foundation |
gmail |
hermes |
fox |
gmbh |
hgtv |
free |
gmo |
hiphop |
fresenius |
gmx |
hisamitsu |
frl |
godaddy |
hitachi |
frogans |
gold |
hiv |
frontdoor |
goldpoint |
hkt |
frontier |
golf |
hockey |
ftr |
goo |
holdings |
fujitsu |
goodyear |
holiday |
fun |
goog |
homedepot |
fund |
|
homegoods |
homes |
investments |
limo |
homesense |
ipiranga |
lincoln |
honda |
irish |
linde |
horse |
ismaili |
link |
hospital |
ist |
lipsy |
host |
istanbul |
live |
hosting |
itau |
living |
hot |
itv |
llc |
hoteles |
kyoto |
jaguar |
hotels |
lacaixa |
java |
hotmail |
lamborghini |
jcb |
house |
lamer |
jeep |
how |
lancaster |
jetzt |
hsbc |
lancia |
jewelry |
hughes |
land |
jio |
hyatt |
landrover |
jll |
hyundai |
lanxess |
jmp |
ibm |
lasalle |
jnj |
icbc |
lat |
jobs |
ice |
latino |
joburg |
icu |
latrobe |
jot |
ieee |
law |
joy |
ifm |
lawyer |
jpmorgan |
ikano |
lds |
jprs |
imamat |
lease |
juegos |
imdb |
leclerc |
juniper |
immo |
lefrak |
kaufen |
immobilien |
legal |
kddi |
inc |
lego |
kerryhotels |
industries |
lexus |
kerrylogistics |
infiniti |
lgbt |
kerryproperties |
info |
lidl |
kfh |
ing |
life |
kia |
ink |
lifeinsurance |
kids |
institute |
lifestyle |
kim |
insurance |
lighting |
kinder |
insure |
like |
kindle |
international |
lilly |
kitchen |
intuit |
limited |
kiwi |
koeln |
maserati |
mtn |
komatsu |
mattel |
mtr |
kosher |
mba |
music |
kpmg |
mckinsey |
mutual |
kpn |
med |
nab |
krd |
media |
nagoya |
kred |
meet |
natura |
kuokgroup |
melbourne |
navy |
llp |
meme |
nba |
loan |
memorial |
nec |
loans |
men |
netbank |
locker |
menu |
netflix |
locus |
merckmsd |
network |
lol |
miami |
neustar |
london |
microsoft |
new |
lotte |
mini |
news |
lotto |
mint |
next |
love |
mit |
nextdirect |
lpl |
mitsubishi |
nexus |
lplfinancial |
mlb |
nfl |
ltd |
mls |
ngo |
ltda |
mma |
nhk |
lundbeck |
mobi |
nico |
luxe |
mobile |
nike |
luxury |
moda |
nikon |
|
moe |
ninja |
madrid |
moi |
nissan |
maif |
mom |
nissay |
maison |
monash |
nokia |
makeup |
money |
northwesternmutual |
man |
monster |
norton |
management |
mormon |
now |
mango |
mortgage |
nowruz |
map |
moscow |
nowtv |
market |
moto |
nra |
marketing |
motorcycles |
nrw |
markets |
mov |
ntt |
marriott |
movie |
nyc |
marshalls |
msd |
obi |
observer |
photo |
pwc |
office |
photography |
qpon |
okinawa |
photos |
quebec |
olayan |
physio |
quest |
olayangroup |
pics |
racing |
oldnavy |
pictet |
radio |
ollo |
pictures |
read |
omega |
pid |
realestate |
one |
pin |
realtor |
ong |
ping |
realty |
onl |
pink |
recipes |
online |
pioneer |
red |
ooo |
pizza |
redstone |
open |
place |
redumbrella |
oracle |
play |
rehab |
orange |
playstation |
reise |
org |
plumbing |
reisen |
organic |
plus |
reit |
origins |
pnc |
reliance |
osaka |
pohl |
ren |
otsuka |
poker |
rent |
ott |
politie |
rentals |
ovh |
porn |
repair |
page |
pramerica |
report |
panasonic |
praxi |
republican |
paris |
press |
rest |
pars |
prime |
restaurant |
partners |
pro |
review |
parts |
prod |
reviews |
party |
productions |
rexroth |
passagens |
prof |
rich |
pay |
progressive |
richardli |
pccw |
promo |
ricoh |
pet |
properties |
ril |
pfizer |
property |
rio |
pharmacy |
protection |
rip |
phd |
pru |
rocher |
philips |
prudential |
rocks |
phone |
pub |
rodeo |
rogers |
security |
solar |
room |
seek |
solutions |
rsvp |
select |
song |
rugby |
sener |
sony |
ruhr |
services |
soy |
run |
seven |
spa |
rwe |
sew |
space |
ryukyu |
sex |
sport |
saarland |
sexy |
spot |
safe |
sfr |
srl |
safety |
shangrila |
stada |
sakura |
sharp |
staples |
sale |
shaw |
star |
salon |
shell |
statebank |
samsclub |
shia |
statefarm |
samsung |
shiksha |
stc |
sandvik |
shoes |
stcgroup |
sandvikcoromant |
shop |
stockholm |
sanofi |
shopping |
storage |
sap |
shouji |
store |
sarl |
show |
stream |
sas |
showtime |
studio |
save |
silk |
study |
saxo |
sina |
style |
sbi |
singles |
sucks |
sbs |
site |
supplies |
sca |
ski |
supply |
scb |
skin |
support |
schaeffler |
sky |
surf |
schmidt |
skype |
surgery |
scholarships |
sling |
suzuki |
school |
smart |
swatch |
schule |
smile |
swiss |
schwarz |
sncf |
sydney |
science |
soccer |
systems |
scot |
social |
tab |
search |
softbank |
taipei |
seat |
software |
talk |
secure |
sohu |
taobao |
target |
toys |
vision |
tatamotors |
trade |
viva |
tatar |
trading |
vivo |
tattoo |
training |
vlaanderen |
tax |
travel |
vodka |
taxi |
travelchannel |
volkswagen |
tci |
travelers |
volvo |
tdk |
travelersinsurance |
vote |
team |
trust |
voting |
tech |
trv |
voto |
technology |
tube |
voyage |
tel |
tui |
vuelos |
temasek |
tunes |
wales |
tennis |
tushu |
walmart |
teva |
tvs |
walter |
thd |
ubank |
wang |
theater |
ubs |
wanggou |
theatre |
unicom |
watch |
tiaa |
university |
watches |
tickets |
uno |
weather |
tienda |
uol |
weatherchannel |
tiffany |
ups |
webcam |
tips |
vacations |
weber |
tires |
vana |
website |
tirol |
vanguard |
wedding |
tjmaxx |
vegas |
|
tjx |
ventures |
weir |
tkmaxx |
verisign |
whoswho |
tmall |
versicherung |
wien |
today |
vet |
wiki |
tokyo |
viajes |
williamhill |
tools |
video |
win |
top |
vig |
windows |
toray |
viking |
wine |
toshiba |
villas |
winners |
total |
vin |
wme |
tours |
vip |
wolterskluwer |
town |
virgin |
woodside |
toyota |
visa |
work |
works |
xn--cckwcxetd |
xn--nqv7f |
world |
xn--cg4bki |
xn--nqv7fs00ema |
wow |
xn--czr694b |
xn--nyqy26a |
wtc |
xn--czrs0t |
xn--otu796d |
wtf |
xn--czru2d |
xn--p1acf |
xbox |
xn--d1acj3b |
xn--pssy2u |
xerox |
xn--eckvdtc9d |
xn--q9jyb4c |
xfinity |
xn--efvy88h |
xn--qcka1pmc |
xihuan |
xn--fct429k |
xn--rhqv96g |
xin |
xn--fhbei |
xn--rovu88b |
xn--11b4c3d |
xn--fiq228c5hs |
xn--ses554g |
xn--1ck2e1b |
xn--fiq64b |
xn--t60b56a |
xn--1qqw23a |
xn--fjq720a |
xn--tckwe |
xn--30rr7y |
xn--flw351e |
xn--tiq49xqyj |
xn--3bst00m |
xn--fzys8d69uvgm |
xn--unup4y |
xn--3ds443g |
xn--g2xx48c |
xn--vermgensberater-ctb |
xn--3pxu8k |
xn--gckr3f0f |
xn--vermgensberatung-pwb |
xn--42c2d9a |
xn--gk3at1e |
xn--vhquv |
xn--45q11c |
xn--hxt814e |
xn--vuq861b |
xn--4gbrim |
xn--i1b6b1a6a2e |
xn--w4r85el8fhu5dnra |
xn--55qw42g |
xn--imr513n |
xn--w4rs40l |
xn--55qx5d |
xn--io0a7i |
xn--xhq521b |
xn--5su34j936bgsg |
xn--j1aef |
xn--zfr164b |
xn--5tzm5g |
xn--jlq480n2rg |
xyz |
xn--6frz82g |
xn--jvr189m |
yachts |
xn--6qq986b3xl |
xn--kcrx77d1x4a |
yahoo |
xn--80adxhks |
xn--kput3i |
yamaxun |
xn--80aqecdr1a |
xn--mgba3a3ejt |
yandex |
xn--80asehdb |
xn--mgba7c0bbn0a |
yodobashi |
xn--80aswg |
xn--mgbaakc7dvf |
yoga |
xn--8y0a063a |
xn--mgbab2bd |
yokohama |
xn--9dbq2a |
xn--mgbca7dzdo |
you |
xn--9et52u |
xn--mgbi4ecexp |
youtube |
xn--9krt00a |
xn--mgbt3dhd |
yun |
xn--b4w605ferd |
xn--mk1bu44c |
zappos |
xn--bck1b9a5dre4c |
xn--mxtq1m |
zara |
xn--c1avg |
xn--ngbc5azd |
zero |
xn--c2br7g |
xn--ngbe9e0a |
zip |
xn--cck2b3b |
xn--ngbrx |
zone |
zuerich |
|
|