Cross-jurisdiction governance and policy interface.
Governance / ICANN
ICANN
ICANN governance intelligence tracks institutions, policy processes, standards activity, registry operations, accountability disputes, and implementation signals that affect internet infrastructure. BTW.

Institutional structure, policy process, and accountability trust.
Multi-stakeholder legitimacy and process clarity.
Structural policy changes usually materialize in 120d+ cycles.
Latest Coverage
Latest from ICANN
167 articles

ICANN
ICANN's NomCom Invites Process Advice, Not Candidate Testimonials
The 2027 consultation puts contributors' views on the public record. It does not turn the selection process into an endorsement campaign.

ICANN
Fifth Allocatable Variant Triggers Full Evaluation Fee
For new applicants, ICANN’s 2026 fee structure includes up to four variant strings, then charges the full evaluation fee for each additional allocatable variant.

ICANN
ICANN’s UA Guidelines Give AI Two Jobs. One Metric Cannot Measure Both
An AI assistant can suggest a better email validator. An AI-powered service can also reject the very address that validator was meant to admit. Those are opposite positions in the same control loop. ICANN’s Universal Acceptance working group now says its final guidance was…

ICANN
A Submitted gTLD Application Still Has a Seven-Day Fee Clock
A timely gTLD submission is not complete for processing until ICANN receives the evaluation fee within the separate payment window.

ICANN
Administrative Check Is a Filing Gate, Not a Merits Decision
ICANN’s Administrative Check verifies filing facts and prepares identical-string sets; it does not approve an application on its merits.

ICANN
One RSP Evaluation Can Cover Many gTLDs—Only for Qualified Services
One evaluation may be reused across gTLDs, but ICANN qualification remains tied to specific registry services.

ICANN
RSP Coverage Is a Function Map, Not a Provider Count
An applicant can name several Registry Service Providers and still leave a critical registry function uncovered. ICANN’s 2026 Round framework is role-specific: Main, DNS, DNSSEC and optional Proxy RSPs carry different functions and different limits on how many may serve a gTLD.

ICANN
Naming an RSP Is Not Contracting Confirmation
An applicant can identify a Registry Service Provider in its application, while ICANN separately seeks confirmation from that provider during contracting. The applicant’s selection, ICANN’s request and any actual RSP response are distinct evidence events.

ICANN
RSP Selection Can Wait Until Evaluation, Not Indefinitely
ICANN’s 2026 rules allow an applicant to submit without naming Registry Service Providers, but that flexibility narrows at evaluation: minimum critical registry functions must be covered, or Extended Evaluation may provide more time.

ICANN
Variant-String Sets Enter Contention Together, Not String by String
ICANN’s 2026 rules treat a primary string and its applied-for allocatable variants as one contention unit when different applicants seek strings from the same variant-string-set. That changes how applicants should map competitive exposure.

ICANN
Existing gTLD Variant Applications Receive Processing Priority, Not Approval
ICANN gives one class of applications an earlier place in the processing order: allocatable-variant applications for existing gTLDs from the 2012 Round. That priority changes sequencing, not the substantive outcome.

ICANN
Existing gTLD Variants Bring the Registry Under One 2026 Agreement
An operator seeking allocatable variants of an existing gTLD is not adding isolated labels to an unchanged contract. ICANN’s 2026 rules require a transition to the new Base Registry Agreement and place the existing gTLD and its variants under one agreement.

ICANN
Only the Existing gTLD’s Registry Operator Can Apply for Its IDN Variants
For ICANN’s 2026 Round, an applicant for IDN variants of an existing gTLD must be the same legal entity as that gTLD’s registry operator.

ICANN
IDN Variants Must Share the Primary gTLD’s Back-End Registry Provider
For ICANN’s 2026 Round, a primary IDN gTLD and its variant strings must use the same back-end registry service provider while they are delegated.

ICANN
Withdrawing a Primary IDN Application Also Withdraws Its Variants
For ICANN’s 2026 Round, withdrawal of a primary IDN application also withdraws every variant string applied for with it.

ICANN
An IDN Variant Application Cannot Precede Its Primary
For ICANN’s 2026 Round, an application for an allocatable IDN variant cannot be submitted before the application for its primary IDN gTLD.

ICANN
For a Proposed Primary IDN, the Choice Can Change Which Variants Are Allocatable
When the proposed primary is not an existing gTLD, the total number of strings in the RZ-LGR variant-string-set stays the same, but its allocatable and blocked subsets can change with the primary choice.

ICANN
ICANN Lets Applicants Withdraw IDN Variants After Submission—but Not Add New Ones
In the 2026 Round, submission fixes the initial primary-and-variant inventory: it may later shrink through withdrawal, but cannot expand.

ICANN
Combining Marks Do Not Satisfy ICANN's Minimum of Two Category-L Code Points for an IDN
ICANN's 2026 IDN rule requires at least two Unicode General Category L code points and excludes Category M code points when determining whether the label is a single character.

ICANN
Language Meaning Does Not Decide Whether an IDN String Passes ICANN's RZ-LGR
ICANN's 2026 Guidebook treats an IDN as a technical DNS identifier before it treats the label as a word. Linguistic meaning and root-zone validity answer different questions.
Member Unlock
Restricted Profile Intelligence
Login is required to unlock full profile briefings and deep-dive sections.
Strategic Circle Briefing
Join to unlock strategic briefings after signing in.
Join Strategic CircleLeadership Alliance Briefing
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance