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.

closed Review of the Registry System Testing 2.0 Test Specifications and API

RequestersICANN org


Only one submission was received, from the Registry Stakeholder Group (RySG). The submission responded in the affirmative to the questions we asked respondents to answer about the implementability of the RST-API and the coverage level of the RST test specs.

The RySG asked ICANN to consider providing an Operational Testing & Evaluation (OT&E) environment for RST v2.0 (which ICANN org already plans to offer) and also asked for clarification on how RST v2.0 would handle testing of Internationalized Domain Names (IDNs) under potential different IDN rules / policies. ICANN org plans to amend the test specifications to provide this clarification in the near future.

What We Received Input On

For the RST API specification, we request commenters to review the API endpoints and JSON schemas that define request and response bodies, and assess whether these are (a) implementable using typical programming languages, libraries, and toolchains; (b) concisely represent the data elements that must be communicated between ICANN and test subjects; and (c) implement all the functionality that test subjects will need to efficiently carry out RST testing, whether for evaluation of Registry Service Providers (RSP); evaluation of gTLDs in Pre-Delegation Testing (PDT) of the New gTLD Program: Next Round, or in day-to-day operations (e.g., Material Subcontracting Arrangement (MSA) change).

For the RST test specifications, we request that commenters review the individual test plans, test suites, and test cases, and assess whether (a) the level of coverage is appropriate, i.e., that all major aspects of the Critical Function (as identified in Section 6 of Specification 10) of the ICANN Registry Agreement as approved by the Board 21 January 2024, Internationalized Domain Names and Registration Validation per Applicable Law with Proxy are tested, and that irrelevant or inappropriate aspects are not tested; (b) the input parameters specified for each suite or test are appropriate and sufficient to allow a test to be carried out; and (c) the error codes defined for each test case cover all possible error conditions, are comprehensible and actionable, and have an appropriate severity level.

Proposals For Your Input
RST Workflow (pdf, 27.42 KB)
RST test specifications (pdf, 2.91 MB)
RST Test Request State Diagram (pdf, 23.43 KB)
RST API specification (pdf, 285.23 KB)


A new Registry System Testing (RST) service is to be developed to comply with Recommendation 39.1 of the Final Report on the New gTLD Subsequent Procedures Policy Development Process, which instructs ICANN org to create such a service.

RST ensures that a Registry Operator has the capacity to operate a new gTLD in a stable and secure manner. Every aspiring Registry Operator (RO) must demonstrate that it has established operations in accordance with the technical and operational criteria described in the Applicant Guidebook prior to delegation into the root zone of the Internet.

Once a gTLD is delegated to the root zone, changes to back-end operations may require a new RST test to ensure the stability of those services.

Additionally, RST will be used to evaluate the technical capabilities of RSP applicants during the RSP Evaluation program of the New gTLD Program: Next Round.

RST covers the following aspects of gTLD registry operations:

  1. Authoritative DNS
  2. DNS Security Extensions (DNSSEC)
  3. Registration Data Access Protocol (RDAP)
  4. Extensible Provisioning Protocol (EPP)
  5. Registry Data Escrow (RDE)
  6. Internationalized Domain Names (IDNs)
  7. SRS Gateway (Standard Amendment Language Registration Validation per Applicable Law with Proxy)

RST v2.0 aims to evolve the current process used in the gTLD space. RST v2.0 will streamline the current service by implementing only automated tests and providing a fully-automated, API-driven workflow. Applicants will use RST v2.0 through an API in a self-testing design, eliminating the need for human intervention.

RST v2.0 will also revise and expand the test specifications, add support for RDAP and IDN-variant gTLDs, and remove support for WHOIS. It will also introduce test plans specifically for use when testing RSPs, Minimum Rights Protection Mechanisms , and DNSSEC operations.

Supporting Information

Supporting Information
The documents in the “Proposals for your input section” are point-in-time snapshots of the “live” specifications that are maintained on GitHub at the following URLs:
These specifications will continue to be updated during the implementation of the new RST system, and as a result of feedback from existing Registry Operators, RSPs and the wider technical community.