Summary

  • The draft bars ICANN from recognising or derecognising a registry unless it has received a proposal the registries have already approved, which puts initiative in the hands of the entities the clause would discipline.
  • The text is published as a draft dated 28 August 2025; no adopting resolution, public comment record or ratification instrument was located, so the 2001 baseline remains the only instrument counterparties can point to.

What is in the record

The document under examination is the Governance Document for the Recognition, Operation, and Derecognition of Regional Internet Registries, published by the Number Resource Organization at the NRO's RIR Governance Document Version 2 page. It is drafted as an instrument, with numbered sections, defined terms and internal cross-references, and it states its own relationship to what preceded it: it succeeds Internet Coordination Policy-2, which it identifies as having been "adopted on 4 June 2001".

Two further pages corroborate the predecessor as a real, dated object. ICANN's page for Internet Coordination Policy-2 and the NRO Address Supporting Organization's ICP-2 reference both describe the 2001 document as the operative baseline for establishing new registries. That corroboration establishes something narrow: the arrangement the draft proposes to replace is publicly indexed by more than one institution. It does not establish what the 2001 document says. Neither page returned readable provision text on 17 October 2026, and this article therefore makes no claim about ICP-2's contents, thresholds or remedies.

The distinction matters because there is a difference between an instrument that exists as text and one that exists as an obligation. The draft exists as text. Whether it exists as an obligation is a question about a resolution, a ratification, a commencement — and on that question the record retrieved here is silent.

Two conditions before any exercise of power

The draft's most consequential provision is a limit on the body that holds the formal power:

ICANN shall have no power to Recognize or Derecognize an RIR unless it has received a Proposal to do so that has been approved by the RIRs in accordance with this Section 2.3.

Three features do the work. First, it is drafted as a disability rather than a grant: it does not say ICANN may recognise a registry, it says ICANN shall have no power to do so except in a specified case. Instruments written this way are usually read as protecting the subject of the power from the power-holder.

Second, two conditions sit between ICANN and any exercise of the power. There must be a Proposal, and that Proposal must already have been approved by the RIRs. The order is explicit: approval precedes receipt. ICANN does not receive an application and then convene the registries; it receives something the registries have already settled.

Third, the effect on initiative is structural rather than procedural. The formal decision-holder cannot open a case against the bodies it would discipline. It can act only on a case those bodies have chosen to bring. Whatever authority the draft confers on ICANN, it withholds the capability enforcement requires: the ability to start.

What the sentence does not say is nearly as important. The cross-reference is to Section 2.3, and that section was not visible in the material retrieved, so the operative threshold is unread. Does a single registry's objection block a proposal, or is it carried by a supermajority? Which bodies must approve — the registries as corporate entities, their memberships, their councils? Over what period, and with what right of reply for the registry in question? Each choice turns the gate from a high hurdle into an absolute bar, and none can be resolved from the excerpt available.

The remedy is written to be hard to use

The draft's treatment of the ultimate sanction is equally specific:

A non-compliant RIR shall be Derecognized only as a last resort and where it is reasonably believed that the harms to the Numbering Community and/or to the Internet Numbers Registry System outweigh the benefits of continuing to tolerate the RIR's non-compliance.

Three conditions are cumulative: non-compliance, last-resort status, and a comparative harm judgment. Three further features are choices rather than accidents.

The standard is a belief standard. It requires that the comparative conclusion be reasonably believed, not that a finding be made on a record. Belief standards are not weak in themselves — much of administrative law runs on reasonableness — but they presuppose a decision-maker whose reasoning can be examined, and the provision does not name one.

The beneficiary of the test is specified, and it is not the decision-maker. The harms that count are harms to the Numbering Community and to the Internet Numbers Registry System. That framing keeps the question away from institutional embarrassment and toward operational consequence, which is the right instinct; it also means that a registry's procedural mistreatment of a member, standing alone, is not obviously the harm the clause contemplates.

The clause is silent on the consequence it triggers. It says a registry shall be derecognised. It does not say what happens to the address space the registry administers, the registration records describing who holds it, the service agreements with its members, or the routing announcements that make the space reachable. That silence is not a technicality. Derecognition is the step in this architecture that a later resolution cannot simply undo, because the thing withdrawn is the authority under which the records were made.

Draft status is part of the finding

The page presents the text as a draft, and the date it carries is part of the document's identity:

28 August 2025 (DRAFT)

Two things should be said honestly. The published page carried that string, and this article reports it as the draft date the publisher prints. Separately, the retained copy of the same page recorded a publication timestamp of 28 August 2026. The discrepancy is left unresolved rather than smoothed over: the draft's vintage is reported as printed, and the observation date for everything here is 17 October 2026. A reader should treat the year of the draft as uncertain and its draft status as clear.

A self-description of draft status proves only how the publisher labels the document. It does not prove that no later instrument superseded it, and it does not prove that no adopting action occurred. What can be said is narrower and still consequential: the document is presented as a draft, the predecessor it names is a 2001 instrument, and no resolution, ratification or commencement instrument bringing the successor into effect was located in the sources retrieved for this article.

Material presented alongside the published text describes further machinery — periodic audits by an independent auditor appointed by ICANN, an emergency continuity arrangement limited to a defined period unless renewed, jointly developed implementation procedures, and adoption by agreement between ICANN and the registries. Those are exactly the provisions that would make the instrument operable, and they are recorded here as description rather than provision, because they were not verified against the instrument's own wording.

The difference matters: a description of an audit duty tells you that someone thought audits belonged in the design; only the text tells you who audits, on what trigger, and what follows a refusal.

What the instrument does not settle, and who carries that risk

Four questions determine whether the arrangement is usable in practice, and none is settled on the record retrieved.

It does not settle the threshold, because Section 2.3 was unread. A gate whose key requirement is undefined is not a gate whose stringency can be assessed.

It does not settle who judges the comparative harm question, on what record, within what time, or subject to what review. A last-resort standard without a named evaluator is a standard that whoever moves first gets to interpret.

It does not settle what happens to resources. Nothing retrieved describes the disposition of a derecognised registry's address space, its registry records, or its members' holdings. For an operator holding allocations, that is the only question that matters, and its absence is the difference between a remedy and a rupture.

It does not settle the position of third parties. Registries deal not only with each other and with ICANN but with members who contract for service, transit providers who route their announcements, and courts asked to enforce or restrain what a registry has done. None of those parties is given a route into the process the draft describes.

Where an instrument leaves those questions open, the risk does not disappear. It is allocated to whoever cannot avoid it: the members and customers of a registry, who must decide whether to rely on a recognition that might be withdrawn without a stated rule about what follows.

Why this reaches past the registry system

The authority to allocate internet number resources is not conferred by a global statute. It is assembled — from operational practice, from the willingness of networks to accept the resulting records, and from recognition by parties outside the registry's own membership. That is why the recognition layer is not a formality. It is where the registry system's authority is either corroborated or left to assertion.

A well-drafted recognition instrument would give counterparties something to point at before a dispute: a named deciding body, stated criteria, a recorded procedure, a defined consequence. A draft that leaves those open, and whose gate clause places initiative with the entities it would discipline, does something different. It confirms where power sits rather than relocating it, and it leaves the effective remedy to whatever forum is available when a dispute becomes urgent.

That is the practical significance of a draft nobody has adopted: not that it is wrong, but that it is not yet load-bearing. A registry facing pressure does not need a successor clause. It needs an instrument in force, and a counterparty needs to be able to say what that instrument requires.

Evidence boundary, dated 17 October 2026

This article rests on four verbatim provisions from the NRO's published page, the printed draft date, and publisher descriptions from three publicly indexed pages at two institutions. It asserts nothing more, and it explicitly does not assert the following.

It does not assert that the draft has been adopted, ratified or approved by ICANN, by the NRO, by the Address Supporting Organization or by any registry. No such instrument was located.

It does not assert that the draft has been rejected or abandoned. The approval track was not read; a gap in what was retrieved is not a finding of absence, and a subsequent adoption action would not contradict anything reported here.

It does not quote or paraphrase the provisions of ICP-2, and it does not assert the approval threshold inside Section 2.3, the identity of the approving bodies, or the existence in the instrument text of the audit, continuity and implementation mechanisms described around it.

It does not assert that any registry is currently non-compliant, that any derecognition proposal exists or has been contemplated, or what would happen to a registry's resources on derecognition.

Two documents would change this picture quickly, and each is a document rather than an argument: a resolution or ratification instrument bringing the successor into effect, or the complete text of Section 2.3. Until one is available, the honest description of this instrument is the one the publisher prints on it — a draft, dated, and not yet the thing anyone can rely on.

Sources