What are the Fundamental Obligations of Registry Operators in relation to Registrars?

In the ICANN ecosystem, the relationship between a Registry Operator (the entity managing the TLD, like .com or .app) and Registrars (the companies that sell domains to the public, like GoDaddy or Namecheap) is strictly governed by the Base Registry Agreement (Base RA).

The "Fundamental Obligations" are designed to ensure a competitive, fair, and stable domain name market.

1. Non-Discriminatory Access

This is the "Golden Rule" of the registry-registrar relationship. A Registry Operator must treat all ICANN-accredited registrars equally.

• Equal Treatment: You cannot offer a lower wholesale price or better technical support to one registrar while charging others more.
• Uniform Terms: All registrars must sign the same Registry-Registrar Agreement (RRA).
• Fair Promotion: If you offer a "sale" or marketing incentive, it must be available to every accredited registrar who wishes to participate.

2. The Registry-Registrar Agreement (RRA)

A Registry cannot simply make up its own rules on the fly.

• ICANN Approval: Any RRA must be consistent with the Base RA. If a Registry wants to make "substantive" changes to its RRA, it must submit those changes to ICANN for a review period (and often a public comment period).
• Transparency: The RRA must clearly outline the technical requirements, payment terms, and compliance standards the registrar must meet.

3. Technical Interoperability (The Shared Registration System)

Registries are obligated to provide a stable Shared Registration System (SRS) that registrars use to register and manage domains.

• EPP Standard: Registries must support the Extensible Provisioning Protocol (EPP), the industry-standard "language" used for domain transactions.
• Performance Specifications: The Registry must meet strict "Service Level Agreements" (SLAs). For example, the SRS must be available 99.4% to 99.9% of the time to ensure registrars can always process orders.

4. Data Handling and WHOIS/RDAP

Registries must maintain an accurate database of all registered domains and provide access to that data.

• Registration Data Directory Services (RDDS): Registries must provide a publicly queryable database (via WHOIS or the newer RDAP protocol) so that registrars and the public can verify domain ownership and status.
• Data Escrow: Registries must regularly "back up" their registration data with a third-party escrow provider. This ensures that if the Registry fails, the registrars (and their customers) don't lose their domains.

5. Vertical Integration Safeguards

If a company owns both a Registry and a Registrar (known as Vertical Integration), there are strict "Code of Conduct" obligations:

• Anti-Abuse: The Registry cannot use its "insider" data to give its own registrar an unfair advantage (e.g., seeing which domains are being searched for and registering them first).
• Separation of Systems: The Registry must maintain clear boundaries to ensure that its wholesale operations don't unfairly subsidize its retail arm.

ICANN new gTLDs: What are the Clarifying Questions?

In the ICANN New gTLD Program, Clarifying Questions (CQs) are formal requests for more information sent by ICANN’s evaluation panels to applicants.

Receiving a CQ does not mean your application has failed. Instead, it means the evaluators found your initial answers insufficient to award a passing score and are giving you a specific opportunity to fix the gaps.

Why You Might Receive a CQ

During the Initial Evaluation (IE) phase, different expert panels review your application. A CQ is triggered if a panel—such as Financial, Technical, or Geographic Names—determines that:

• An answer is incomplete or unclear.
• The provided financial data doesn't align with the proposed scale of the registry.
• Technical documentation lacks specific details on DNS stability or security.
• The applicant's entity structure requires further legal proof.

ICANN new gTLDs: What is the Prioritization Draw?

In the context of ICANN’s New gTLD Program, the Prioritization Draw is a randomized process used to assign a "priority number" to every application. This number determines the order in which applications are processed through initial evaluation, pre-delegation testing, and eventually, the execution of registry agreements.

Because ICANN receives a massive volume of applications in a short window, it cannot process all of them simultaneously. The draw ensures that the queue is formed in a fair, transparent, and neutral manner.

How the Draw Works

The process was first introduced in the 2012 round and has been refined for the upcoming 2026 Round. Here is the typical breakdown of the event:

• The "Lottery" Format: It is a manual, live event. In past rounds, physical paper tickets representing each application were placed in a drum and drawn by hand to ensure the process could not be "gamed" by digital timestamps.
• Optional Participation: Applicants generally have the choice to participate by purchasing a ticket (historically around $100). Applications with tickets are drawn first; those without tickets are assigned priority numbers afterward.
• Categorization: To promote linguistic diversity, Internationalized Domain Names (IDNs)—which use non-Latin scripts like Arabic, Chinese, or Cyrillic—are typically prioritized and drawn in the first group.