Transitioning to ICANN's Registration Data Policy (RDP For Registrars)

Overview

ICANN's Registration Data Policy (RDP) requires registrars to support the transition from a Maximum (THICK) Data Set to a Minimum (THIN) Data Set. This document provides a detailed timeline, technical guidelines, and considerations specifically tailored for registrars.

For a list of Registry Operators, TLDs and their decision in this context, please refer to this article.

Key Changes

Data Set Definitions

Maximum Data Set (THICK)

Previously this mode required 4 contacts, as from Phase 2 Billing and Tech can be omitted without causing an error.

If a TLD is in this mode, 2 contacts (Registrant and Tech) are required. Admin and billing contacts will become obsolete.

The system will not error if they are supplied, but will silently ignore these and no contact data will be saved for admin and billing contacts, this also means that these will not be present in INFO responses.

Minimum Data Set (THIN)

Prohibits collection of all contact information at the registry level. If a TLD is in this mode, no contacts can be supplied. If they are supplied, the command will fail with error.

THIN-INTERIM

If a TLD is in this mode, contacts will be accepted, saved and displayed in info requests, so if the registrar still supplies contacts, the command will complete successfully.

Technical Transition for TLDs migrating to Minimum Data Set

Phase 1: Optional Contact Objects

• TLDs staying on Maximum Data Set work like THICK

Start Date: March 3rd, 2025

• TLDs migrating to Minimum Data Set will be in THIN-INTERIM mode.

• Contact objects become optional.

• Domain registrations and updates can omit contact information.

• Domain registrations and updates with contact information are still allowed until the next phase.

Phase 2: Rejection of Prohibited Data

• TLDs staying on Maximum Data Set work like THICK

Start Date: July 8th, 2025

• TLDs migrating to Minimum Data Set will be in THIN mode.

• The registry system will reject any contact information.

• Domain creation or updates containing contact data will fail.

Phase 3: Contact Object Purge

• TLDs staying on Maximum Data Set work like THICK

Start Date: August 5th, 2025

• All contact objects will be permanently purged from the registry system.

System and API Modifications

UI and User Experience Changes

• RDAP UI replaces WHOIS UI, clearly indicating contact information should be obtained through registrars.

• User Interfaces (Registrar Console and Portal) will display a warning when adding contacts during the THIN-INTERIM phase.

EPP Protocol Changes

Domain Create without Contacts (THIN)

<domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
  <domain:name>create.thin</domain:name>
  <domain:authInfo>
    <domain:pw>yHfz0Wc0UL2AEA]jZbiXdHm63k!NcJrUa3a8Zqfw</domain:pw>
  </domain:authInfo>
</domain:create>

Domain Create with Contacts Error (THIN)

<create>
  <domain:create xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    <domain:name>create.thin</domain:name>
    <domain:registrant>H123456</domain:registrant>
    <domain:authInfo>
      <domain:pw>yHfz0Wc0UL2AEA]jZbiXdHm63k!NcJrUa3a8Zqfw</domain:pw>
    </domain:authInfo>
  </domain:create>
</create>
<!-- Error Response -->
<result code="2004">
  <msg>Contacts are prohibited for this suffix</msg>
</result>

Domain Update Removing Contacts (THIN-INTERIM)

<update>
  <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    <domain:name>domain.interim</domain:name>
    <domain:chg>
      <domain:registrant/>
    </domain:chg>
  </domain:update>
</update>
<!-- Success Response -->
<result code="1500">
  <msg>Command completed successfully.</msg>
</result>

Domain Update Adding Contacts Error (THIN)

<update>
  <domain:update xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
    <domain:name>domain.thin</domain:name>
    <domain:add>
      <domain:contact type="admin">H12345</domain:contact>
    </domain:add>
  </domain:update>
</update>
<!-- Error Response -->
<result code="2306">
  <msg>Contact information is prohibited for this suffix</msg>
</result>