Primary Domain
Internet Governance and Routing
Within the Primary Domain facet, Internet Governance and Routing intelligence groups reporting by primary domain so readers can follow a focused area of internet infrastructure, governance, connectivity markets, or digital capital. The page brings together related articles, public evidence, institutions, companies, people, regional exposure, operating dependencies, and market context that may otherwise sit across separate category pages. It explains the domain, the likely actor class, the market or governance context, and the source material readers should use when comparing signals. Operators, analysts, and governance readers can see how the same domain appears across events, profiles, market shifts, public-source evidence, regional dependencies, and longer-cycle infrastructure decisions over time.

ICANN
A .Brand String Change Can Add Words, But Cannot Create or Expand Contention
ICANN’s 2026 Round gives a qualifying .Brand applicant a narrow way to change a string when contention arises. It is not a general opportunity to rename an application.

ICANN
A Material Change to Public Application Content Opens 30 Days of Comment, Not Automatic Approval
When ICANN finds that a requested change materially affects public application content, the request enters a 30-day comment process but has not crossed the approval line.

Number Resource Society
An RPKI Cache Serial Is Not a Freshness Timestamp
Two RPKI caches can report perfectly accurate serial numbers and still tell an operator nothing about which cache holds newer global data. RFC 8210 scopes a serial to one cache session and protocol version. Treating the larger number as the fresher view manufactures a chronology…

ICANN
GAC Consensus Advice Starts a 21-Day Response Record, Not an Automatic Board Outcome
Formal GAC Consensus Advice changes the applicant's procedural position, but it does not itself supply the ICANN Board's decision.

ICANN
A GAC Early Warning Is a Signal, Not a Veto: The Applicant's Response Record
The 2026 Round gives a government representative a way to flag a concern without turning that notice into an automatic decision on the application.

ICANN
A Singular/Plural Risk Does Not Self-Execute: The 30-Day ICANN Notification Record
In the 2026 Round, a grammatical pair becomes a program decision only through a timely notification backed by verifiable dictionary evidence.

ICANN
An ICANN Objection Appeal Is Not a Retrial: What the Clearly Erroneous Standard Can Change
The 2026 Round appeal process reviews an identified objection error; it does not reopen the entire dispute from the beginning.

ICANN
Community Objection Is Not CPE: Two ICANN Procedures That Test Different Claims
The word “community” appears in both names, but the procedures ask different questions, involve different parties and create different records.

ICANN
What Evidence Record Should a Community Priority Evaluation Applicant Build?
A criterion-linked record is more useful than a pile of endorsements.

CASE FILE
Sixty Names Were Defendants; the Statute Still Defined the Claim: Harrods v Sixty Internet Domain Names
The caption did something unusual: it named sixty domain names as defendants. That procedural choice made a dispute over the Harrods name look, for a moment, like a dispute over things rather than people. The Fourth Circuit’s answer was narrower. The names could be before the…

ICANN
ICANN Checks Every Applied-for String for Geographic Meaning. What Must a Support Letter Prove?
ICANN’s 2026 Round checks every applied-for string for geographic meaning. Applicants need an authoritative, authentic and scope-correct support record—not merely a letter.

IETF
Corey Bonnell and the CRL Signature Whose Key Was Not Authorized
A certificate revocation list can carry a flawless digital signature and still be signed by the wrong certified key. RFC 10007 closes that uncomfortable gap by requiring a version 3 CRL issuer certificate to say, explicitly, that its key may sign CRLs. The change turns a skipped…

IETF
Kireeti Kompella and the Echo Reply That Did Not Prove the Service
An MPLS Echo Reply can show that one carefully constructed probe reached a router able to account for a particular forwarding equivalence class. That is a precise and valuable result. It does not show that every equal-cost path worked, that a dormant backup was usable, that the…

IETF
Eliot Lear and the Device Policy That Was Never an Attestation
A limited-purpose device can tell a network which communications it needs without proving what the device is, who currently controls it, or whether it will behave as described. RFC 8520 makes that narrow statement useful through Manufacturer Usage Description, then leaves the…

IETF
Tero Kivinen and the New IKE SA That Inherited Live Child SAs
In IKEv2, the word “rekey” can describe two materially different successions. Replacing the protected control association creates a new IKE SA, yet the Child SAs carrying ESP or AH traffic can remain exactly the ones already in service. The distinction documented in RFC 7296…

IETF
Roy Fielding and the Method That Named an Intention, Not a Permission
An HTTP request begins with a compact public word. That word can tell a client, cache or intermediary what kind of result is being sought. It cannot say who is entitled to obtain it, whether the target will comply, or what happened after a connection failed. The architecture…

IETF
Mark Nottingham and the User Agent That Could Not Speak for Every User
The browser can deny a service direct access to a person's machine, carry a narrow preference and make another implementation possible. Those powers make the user agent a valuable intermediary. They do not turn software, its vendor or a standards entity into the authorized voice…
