fr

Public Comment

Public Comment is a vital part of our multistakeholder model. It provides a mechanism for stakeholders to have their opinions and recommendations formally and publicly documented. It is an opportunity for the ICANN community to effect change and improve policies and operations.

Proposed Amendments to the Base gTLD RA and RAA to Add RDAP Contract Obligations

CategoryTechnical
RequestersICANN org
ICANN org Contact(s)karla.hakansson@icann.org

What We Received Input On

ICANN org and members of the Registries Stakeholder Group (RySG) and the Registrar Stakeholder Group (RrSG), collectively the Contracted Party House Negotiating Team (CPH NT), are seeking input from the ICANN community on the proposed amendments to the base generic top-level domain (gTLD) Registry Agreement (RA) and 2013 Registrar Accreditation Agreement (RAA).

The proposed amendments specify operational requirements for providing Registration Data Directory Services (RDDS) via Registration Data Access Protocol (RDAP), and to phase out certain obligations to provide RDDS via the WHOIS protocols. ICANN org and the CPH NT took care when negotiating these changes to define a plan that would allow users time to prepare their systems and procedures to utilize the RDAP protocol to query for domain name registration data as they do today using the WHOIS protocols. Ultimately, users can continue to lookup domain registration data in gTLDs using “clients” or tools like ICANN’s easy-to-use lookup tool available at https://lookup.icann.org.

It is important to note that the requirements outlined in the amendments do not change the data elements required to be collected, transferred, escrowed, displayed, or redacted by registries or registrars, as those requirements are detailed in ICANN Consensus Policies. Additionally, the agreements do not create or modify any obligations related to disclosure of personal registration data to third party requestors. The proposed agreements contain the foundational requirement for both registries and registrars to comply with the RDAP Profile to ensure registries and registrars provide responses via RDAP in a standardized format and consistent with the ICANN Consensus Policies. For more information about the RDAP Profile, please see https://www.icann.org/gtld-rdap-profile.

ICANN org and the CPH NT are seeking input from the ICANN community on the following proposed contractual requirements:

  • A requirement to comply with the gTLD RDAP Profile.
  • Updated definitions for RDDS related terms; this includes updating Specification 13 for .BRAND Registry Operators.
  • Reporting requirements for registries that include changes to address the advice from the ICANN Security and Stability Advisory Committee in SAC097 related to inconsistent reporting of RDDS queries.
  • Service Level Requirements for RDAP availability, round-trip time, and update time.
  • The plan to sunset certain requirements to provide RDDS via the WHOIS protocols over a period of 18 months from the contract effective date.
  • The requirement for registrars to provide RDAP for all gTLD Domains Under Management (DUMs) eliminating the option for registrars supporting registries that provide complete contact information to relay the registration data from the registry.
  • A change to the language of Specification 4, Section 3.1 that will enable ICANN org to use the existing Bulk Registration Data Access (BRDA) for research purposes. The BRDA change enables ICANN to use this data to conduct important research for projects such as extending the DAAR to registrars. DAAR is a system for studying and reporting on domain name registration and security threats. The overarching purpose of DAAR is to develop a robust, reliable, and reproducible methodology for analyzing security threat activity (domain abuse), which the ICANN community may use to make informed policy decisions.
  • Updates made to clean-up Uniform Resource Locator (URL) web addresses in the RA and to make miscellaneous editorial changes (e.g., URLs updated to “https” from “http”) to address outdated links and clarifications to current requirements.

Proposals For Your Input
Proposed REDLINE to Specification 13 (pdf, 252.45 KB)
Proposed REDLINE 2013 Registrar Accreditation Agreement (pdf, 735.44 KB)
Proposed Global Amendment to the base gTLD Registry Agreement (pdf, 333.7 KB)
Proposed CLEAN 2013 Registrar Accreditation Agreement (pdf, 710.33 KB)
Proposed CLEAN Specification 13 (pdf, 139.84 KB)
Proposed CLEAN base gTLD Registry Agreement (pdf, 951.48 KB)
Proposed REDLINE base gTLD Registry Agreement (pdf, 795 KB)
Proposed Global Amendment to Specification 13 (pdf, 129.07 KB)
Proposed Global Amendment to the Registrar Accreditation Agreement (pdf, 362.44 KB)

Background

In 1982, the Internet Engineering Task Force (IETF) issued the WHOIS protocol as a directory service for ARPANET users and this protocol has been in place for domain names in the Domain Name System (DNS) ever since. In 2010, the ICANN community held discussions about the need for the technical evolution of the WHOIS service citing that the WHOIS protocol does not meet the community’s needs. On 19 September 2011, the ICANN Security and Stability Advisory Committee (SSAC) issued SAC051 advising the ICANN community to evaluate and adopt a replacement for the WHOIS protocol. The SSAC made the recommendation based on the shortcomings found with WHOIS such as the:

  1. Lack of support of internationalization
  2. Secure access to data
  3. Differentiated access
  4. Standardized query, response, and error responses. 

The ICANN Board adopted the advice from SAC051 on 28 October 2011 and directed ICANN org to produce, in consultation with the community, a roadmap for the coordination of the technical and policy discussions necessary to implement. Subsequently, RDAP was developed by the technical community vis-a-vis the IETF as described in STD95

On 17 May 2018, the ICANN Board passed a resolution adopting a Temporary Specification for gTLD Registration Data requiring:

  1. Registry operators and registrars to operate a RDAP service
  2. ICANN org and the community to define the appropriate RDAP profile(s)
  3. Registry operators and registrars to implement the service no later than 135 days after being requested by ICANN

In February 2019, the gTLD RDAP Profile, a technical specification for gTLD registries and registrars detailing uniform implementation of the RDAP services, was developed with the support of the contracted parties and aligned the RDAP requirements to the Temporary Specification for gTLD Registration Data. ICANN org required the contracted parties to implement the RDAP protocol by 26 August 2019 and recommended they comply with the RDAP Profile. 

RDDS, commonly known as "the WHOIS System,” will continue to be provided by the gTLD registries and ICANN-accredited registrars in accordance with ICANN Consensus Policies. The proposed amendments are the culmination of a long-standing commitment to the Internet community to improve the WHOIS system by replacing the WHOIS protocols with the more capable RDAP protocol.

RDAP enables access to current registration data and was created as an eventual replacement for the WHOIS protocols. Offering many advantages over the current WHOIS protocols, RDAP standardizes queries, provides protocol support for standardized authentication, extensibility, mechanisms for differentiated access, support for internationalized registration data, and a referral mechanism. Developed by the technical community and standardized in the IETF via a series of Request for Comment (RFC) documents, RDAP is the protocol that will allow the WHOIS system to support current and future policies.

Both the RA (Section 1 of Specification 4) and the RAA (Section 1 of the Registration Data Directory Service (WHOIS) Specification) contemplated the development of and transition to a new technical protocol to replace the WHOIS protocols to deliver the RDDS. The agreements state that, “Until ICANN requires a different protocol…” Registry/Registrar will operate a WHOIS service available via port 43 in accordance with RFC 3912 and a web-based Directory Service providing free public query-based access as specified.” 

In February 2019, pursuant to requirements in the RA, RAA, and the Temporary Specification for gTLD Registration Data, ICANN org triggered the obligations for all registries and registrars to implement RDAP by 26 August 2019. Subsequently in October 2019, ICANN org initiated negotiations with the RySG and RrSG to develop amendments to the RA and the RAA to specify the operating requirements for RDAP and to define the plan to sunset obligations to provide RDDS via the WHOIS protocol. In June 2021, ICANN org and the contracted parties also began discussing the desire to extend the Domain Abuse Activity Reporting (DAAR)  project metrics to the registrar level, and reached agreement in principle on the concept in October 2021. The resulting proposed amendments incorporate:

 

  • The reporting requirements and service level requirements for RDAP.
  • The requirement for both registries and registrars to comply with the RDAP Profile to ensure registries and registrars provide responses via RDAP in a standardized format and consistent with the ICANN Consensus Policies.
  • The sunset of certain obligations to provide RDDS via the WHOIS protocols (i.e., WHOIS port-43 and web-based WHOIS) 18 months after contract effective date.
  • The allowance for ICANN to use an existing data set provided by registries for research purposes. This change will enable ICANN to extend the Domain Abuse Activity Reporting (DAAR) project metrics to registrars to study DNS security threat concentrations across registrars.

Next Steps

Following the Public Comment proceeding, submission will be reviewed and considered by ICANN org and the CPH NT, and the Public Comment Summary Report will be published. After the Public Comment process, ICANN will administer a 60-day voting period for the contracted parties to approve the respective amendments.

If the proposed amendments receive the required supermajority of votes by registry operators and registrars for their respective agreements the proposed amendments will be sent to the ICANN Board for consideration.