Review of the Registry System Testing 2.0 Test Specifications and API

What We Need Your 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.

Background

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.

Next Steps

The Public Comment period will close on 6 May, 2024 and ICANN org will release a Public Comment Summary report. ICANN org will consider the comments and make updates, as appropriate, to the RST API specification and test specifications. The org will then publish an addendum to the report with a review of the Public Comments it received.

Supporting Information

This additional information from ICANN org provides more context for this Public Comment Proceeding and may help you review the proposals for input and publish a submission.