2023 GLOBAL AMENDMENT TO REGISTRY AGREEMENTS

 

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.  ICANNs 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 ICANNs 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 ICANNs 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 recipients 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 ICANNs 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:

 

9.         References.

(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.      Whois Data Directory Services after the Whois Services Sunset Date.  If Registry Operator continues to offer WHOIS Data Directory Services after the WHOIS Services Sunset Date the following requirements will apply:

 

1.5.1    If Registry Operator continues to offer a WHOIS service available via port 43, Registry Operator shall do so in accordance with RFC 3912.

 

1.5.2    Registry Operator shall submit a change request to the IANA functions operator updating any outdated or inaccurate WHOIS records of the TLD as described in Specification 6, Section 1.6.

 

1.5.3    Personal data included in registration data must be redacted in accordance with ICANN Consensus Policies and Temporary Policies;

 

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.5.5    If the Registry Operator provides less registration data in WHOIS Data Directory Services than that available in the RDAP Directory Services, Registry Operator must add the following disclaimer in the WHOIS output footer: “The registration data available in this service is limited.  Additional data may be available at https://lookup.icann.org”.

 

1.5.6    After the WHOIS Services Sunset Date, in the event of a conflict between the WHOIS Data Directory Service requirements and Consensus Policies or any Temporary Policy effective after the WHOIS Services Sunset Date, the Consensus Policies or Temporary Policy shall control, but only with respect to subject matter in conflict.

 

1.5.7    Until such time that updates are made and effective for Consensus Policies and procedures pursuant to the Phase 1 GNSO Consensus Policy recommendations of the Expedited Policy Development Process on the Temporary Specification for gTLD Registration Data, adopted by the ICANN Board in May 2019, as of the WHOIS Services Sunset Date, the following terms in such policies will be interpreted as follows:

 

(1)       With the exception of “Searchable Whois” and the “Whois contact lookup service”, the following terms: “WHOIS”, “Whois”, “Whois service”, “Publicly accessible Whois”, and variations thereof shall be interpreted to refer to RDDS as defined in this Specification.

 

(2)       “Whois data”, “WHOIS information”, “Whois contact information”, “WHOIS query data”, “WHOIS details”, “Whois output”, “Whois record”, “Whois entry”, and variations thereof shall be interpreted to refer to registration data as referenced in this Specification.

 

1.6.      After the WHOIS Services Sunset Date, the terms in 1.5.7(1) and 1.5.7(2) above, included in Exhibit A and Specifications 11 and 12 will be interpreted as defined in 1.5.7(1) and 1.5.7(2).

 

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 MaterialsRegistry 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 Operators 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 Operators 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:

 

1.6.      [Intentionally Omitted]

 

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:  

 

 

Parameter

SLR (monthly basis)

DNS

DNS service availability

0 min downtime = 100% availability

 

DNS name server availability

432 min of downtime ( 99%)

 

TCP DNS resolution RTT

1500 ms, for at least 95% of the queries

 

UDP DNS resolution RTT

500 ms, for at least 95% of the queries

 

DNS update time

60 min, for at least 95% of the probes

EPP

EPP service availability

864 min of downtime ( 98%)

 

EPP session-command RTT

4000 ms, for at least 90% of the commands

 

EPP query-command RTT

2000 ms, for at least 90% of the commands

 

EPP transform-command RTT

4000 ms, for at least 90% of the commands

RDAP-RDDS*

RDAP availability

864 min of downtime ( 98%)

 

RDAP query RTT

4000 ms, for at least 95% of the queries

 

RDAP update time

60 min, for at least 95% of the probes

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

 

 

Parameter

SLR (monthly basis)

WHOIS-RDDS

WHOIS-RDDS availability

864 min of downtime ( 98%)

 

WHOIS-RDDS query RTT

2000 ms, for at least 95% of the queries

 

WHOIS-RDDS update time

60 min, for at least 95% of the probes

 

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

 

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 probesICANN 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 probesICANN 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.         Emergency Thresholds

 

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

RDAP-RDDS*

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.

 


Critical Function

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.

 

 


Schedule A

 Applicable Registry Agreements – Identified by TLD

 

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

email

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

google

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

weibo

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

 

 

 



[1] Field is optional.

[2] Field is optional.