Summary

  • The latest recommended RIR governance draft uses two-thirds support for recognition and derecognition, with different denominators and safeguards. It does not give a registry a veto over its own removal.
  • ICANN and qualifying groups of members could initiate a derecognition proposal. As of ARIN's 22 October update, adoption and further community input were still ahead.

Strip an Internet registry of its status and a practical question follows: who will do its job next? Networks still need the address records and services that the registry maintains. A governance dispute does not make that work disappear.

A proposed overhaul of Regional Internet Registry governance tries to connect those two responsibilities: deciding which institution should be recognised, and keeping services available when that responsibility changes hands. It also tackles an awkward question at the other end of a registry's life. Who should judge a newcomer when its arrival could cost an existing registry members or revenue?

Under the latest proposed rules, registries would submit their assessments, reasons and relevant interests to ICANN. In a recognition case, ICANN could exclude a negative recommendation from the voting threshold if the proposed newcomer would materially affect that registry's service region or revenue—but only after written notice, reasons and a fair chance to respond. The excluded opinion would still inform the review. Having something to lose would not make an objection wrong; it would make the reasons worth examining.

This is a more complicated arrangement than either an incumbent veto or an ICANN free hand. It appears in the Version 3 recommended draft, published on 1 September 2026. The ASO's accompanying explanation identifies a two-thirds threshold, conflict disclosures and published assessments among the changes from Version 2. Those are changes to a proposal, not powers that publication alone brings into force.

An application, not a settled deal

A candidate would apply to both the registries and ICANN. Existing registries would assess it individually, and ICANN would review the application and their recommendations. Recognition would require support from at least two-thirds of the registries submitting assessments, subject to the exclusion procedure above. Meeting that threshold would not itself grant recognition: ICANN would still decide and explain its decision, and a successful application would face a transition plan's conditions.

That sequence matters. The applicant is not required to arrive at ICANN carrying a deal already settled beyond its scrutiny. Nor could ICANN simply ignore the peer-support requirement. The proposed system combines an application, individual assessments, a voting condition and a final decision. Collapsing those steps into “the registries control the agenda” loses what each party can actually do.

The distinction is sharper when the question is removing recognition. A proposal could come from any RIR, ICANN, or members numbering at least 25% of the affected registry's membership or 2,000 members, whichever is lower. The eventual support threshold would be at least two-thirds of the other registries; the registry under examination would not count toward it. Initiating a case and winning it are separate hurdles. Neither a group of members nor ICANN could turn a complaint directly into removal.

Removal would come with a handover

Rehabilitation remains the preferred course. Under Article 6 of the authoritative draft PDF, derecognition concerns a registry that remains materially non-compliant despite a reasonable opportunity to remedy its failures. ICANN would make the final decision, with published reasons and a transition plan where removal is approved.

The text also addresses what follows: a successor or interim operator would receive the affected registry's services and operations under that plan. For the networks using those services, this is the part that turns an institutional decision into a practical undertaking. Somebody must be ready to take over. A transition plan cannot guarantee an effortless transfer, but a requirement to make one is not silence about the day after a decision.

A separate emergency route would allow temporary provision of affected services. The registry could initiate it for itself; alternatively, ICANN and two-thirds of the other registries could do so. An arrangement would last no more than 90 days unless renewed, with a right to resume services once restored capability had been verified. Temporary continuity and permanent derecognition should not be confused.

The NRO's review FAQ explains why the revision ranges beyond admitting new registries: it addresses recognition, ongoing accountability and potential derecognition across an institution's life. For an address holder, the useful question is not just who signs the recognition decision. It is who must keep the registry service working while institutional responsibilities change.

The next decision is still adoption

“Final draft” is an easy label to overread. In ARIN's 22 October meeting account, its Chief Legal Officer, Michael Abejuela, said the NRO Executive Council had provided the document to ICANN for consideration. He still listed a last call, public comment, adoption by the RIR and ICANN boards, and implementation procedures as work ahead. That is affirmative evidence of the process's stage, not a conclusion drawn from failing to find a resolution.

The earlier draft was not as empty as our previous article suggested, either. The full Version 2 text, dated 28 August 2025, already described who could initiate derecognition, excluded the affected registry from peer approval and provided for a handover. The newer text changes important thresholds and procedures. An unread clause in the older one was never evidence that no rule existed.

These proposals do not establish misconduct by any registry or show that a particular removal case is under way. Members and ICANN could put a problem on the agenda; peer registries would have to take a reasoned position; ICANN would decide within specified limits. If those rules are adopted, any future case will still have to answer the opening question. A decision about a registry is not complete simply because the votes have been counted: the networks it serves need to know who will do the work next.

Correction and update, 24 October 2026: this article now covers Version 3 and the 22 October process update. The previous account incorrectly inferred that ICANN could not initiate derecognition, that the affected registry could veto its own removal, and that handover provisions were absent. It also overlooked published consultations. The draft date for Version 2 is 28 August 2025; a conflicting page timestamp was not a sound basis for treating that date as unknown.