Summary

  • Applicants must specify the RSPs that would deliver critical registry services if an application proceeds to delegation.
  • During contracting, ICANN separately seeks confirmation from the identified RSP that it acknowledges plans to support the applicant and the relevant gTLD or gTLDs.
  • An applicant may specify or change selected RSPs after submission through the Application Change Request process.

This article uses two records to explain the Guidebook’s two supported events. The first is the applicant’s identification of the Registry Service Provider it intends to use. For the second, ICANN seeks confirmation during contracting from the RSP about its plans to support that applicant and the relevant gTLD or gTLDs. The two-record framing is BTW analysis, not an ICANN requirement.

The distinction is narrow but operationally important. A provider name entered by an applicant records the applicant’s intended arrangement. It does not, by itself, record the provider’s later acknowledgement. During contracting, ICANN seeks that separate confirmation from the identified provider; the request does not prove that a response has been received.

The Guidebook also allows an applicant to specify or change selected RSPs after submission through the Application Change Request process. That means the RSP record can evolve before contracting. Teams should therefore retain the reason, date and scope of each selection change instead of treating the first provider name as the final contracting record.

This does not mean that an identified provider has refused support, that a contract will or will not be executed, or that delegation is assured. It means only that applicant-side identification and provider-side acknowledgement answer different questions.

Analysis

For application governance, the clean control is a two-record chain. The application record should show which RSPs the applicant identifies for the proposed registry services. The contracting record should show the provider-side acknowledgement requested by ICANN for the applicant and the relevant string or strings.

Keeping those records separate makes changes easier to audit. This two-record chain is BTW governance guidance, not an ICANN-mandated recordkeeping obligation. If an applicant changes an RSP through the Application Change Request process, the team can identify which earlier selection was superseded and from which provider ICANN would later seek confirmation. The approach also prevents internal planning documents from presenting an applicant’s intention as if it were evidence supplied by the provider.

Sources