Summary

  • Version 3 adds a route for an affected RIR to initiate a temporary handover of its own services; another route lets ICANN and two-thirds of the other RIRs initiate or renew one.
  • The text caps each arrangement at 90 days and gives the affected RIR a right to resume service after capability is restored and verified, but does not expressly say how a self-started arrangement is renewed.

The route changed before the operator did

When a registry cannot adequately provide part of its services, the proposed RIR Governance Document permits a qualified Temporary Emergency Operator to provide the affected work temporarily. That can concern an important control surface: delegating number resources, maintaining registrations and directory data, or the related technical services that let resource holders and other networks rely on current records. The draft does not say that a temporary operator becomes the RIR. It describes a bounded transfer of specified services.

AFRINIC’s 1 September 2026 news notice shared the ASO AC Recommended Draft, its redline and a rationale report. The NRO page calls Version 3 a final draft; the NRO timeline says the ASO AC/NRO NC delivered it to the NRO Executive Council on 28 July. Finalisation and Q4 approval/adoption remain steps ahead as of 14 October. The text is therefore a proposed system-wide rule, not a current operating procedure. Neither the notice nor the draft establishes that AFRINIC—or another RIR—is unable to serve its region. AFRINIC shared the package; the NRO’s Version 3 text supplies the clauses analysed here.

Two initiation paths

Section 5.1(a) is a meaningful change from Version 2. If an RIR cannot adequately provide all or part of its services, it may initiate an arrangement for its own services. Version 2 instead required unanimous agreement of the other RIRs and ICANN to initiate the arrangement. Version 3 keeps a cross-RIR path in 5.1(b), but lowers that external threshold: an arrangement may also be initiated or renewed with ICANN and two-thirds of the other RIRs, after discussion with the affected RIR and its community where reasonably possible.

The rationale explains the choice in operational terms. A self-start could help during a natural disaster; a lower external threshold can shorten response time. The drafters also retained the 90-day limit so a temporary arrangement would not become the default mode of operation. Those are coherent objectives. In a fast-moving disruption, requiring a regional institution to wait for a wider approval process before it can ask for continuity support may prolong uncertainty about who can perform a critical registry task.

But initiation and renewal are not the same decision. Paragraph (a) names the affected RIR as the actor that may initiate its own service handover. Paragraph (b) expressly says an arrangement may be “initiated or renewed” with ICANN and two-thirds of the other RIRs. Paragraph (c) says an arrangement may not exceed 90 days unless renewed under the conditions in the section. It does not expressly state whether an RIR that initiated under (a) may renew its own arrangement, or whether renewal must use the (b) agreement route.

That omission supports more than one reading. The explicit renewal language in (b) can be read as making the cross-RIR agreement the only stated renewal path. Another reading is that an affected RIR’s authority to start under (a) can extend to renewing the continuity arrangement it initiated. Section 5.1(f), which refers to the “relevant initiating party (or parties)” under (a) or (b) when scope changes, makes it harder to treat the two paths as unrelated. It does not, however, expressly answer the renewal question.

This is a drafting ambiguity to clarify, not a conclusion that one interpretation is legally settled or that a self-started arrangement cannot continue.

Scope is part of authority

The renewal question matters because the services covered are not fixed permanently at the first handover. Section 5.1(f) allows the scope of affected services to increase or decrease during an arrangement or upon renewal, as considered necessary by the relevant initiating party or parties. If the affected RIR initiated and the external group later agreed to renew, the draft should make clear who can narrow the operator’s remit, add a service, or decide that a changed condition warrants a different division of work.

This is not administrative bookkeeping. Each service added to a temporary operator changes what the affected RIR continues to control directly; each service removed changes the handback work and the evidence needed to show that the registry can resume it. The document’s opening test—an inability to provide all or part of RIR Services—also leaves operational judgment in the process. A decision record should identify which service failed the adequacy test and what evidence would later count as restored capability, without publishing sensitive credentials or security details.

The other provisions supply important guardrails. Section 5.1(d) requires ICANN promptly to publish each initiation or renewal decision, its rationale and scope. It calls for engagement with all RIR communities after initiation; extra RIR-community engagement after renewal is optional. The affected RIR must cooperate with the temporary handover and retains the right to resume the relevant services once operational capability is restored and verified.

Section 5.2 then requires a joint post-event review and a public report on the circumstances, services, duration and return process, alongside operator evaluation, community feedback and recommendations.

Those safeguards improve visibility and make a temporary operator answerable to a defined remit. They do not themselves state who has renewal authority after the local route is used. Nor should community engagement be mistaken for a substitute decision right: affected operators and users can provide evidence, warnings and technical knowledge, while the draft still assigns institutional decisions to identified actors.

Procedures should expose the handoff

Section 1.3 anticipates implementation procedures but says their absence does not prevent the document’s provisions from being enforceable; each RIR retains discretion to determine its compliance approach within the document’s wider obligations. Section 1.4 points decisions to the relevant entity’s own procedures, including any challenge or appeal. A shared emergency playbook could therefore make operational steps more precise, but it should not leave the basic division of authority to be reconstructed during the event.

A compact authority-path record would make the draft testable. For each arrangement, it could identify the initiating clause and decision-maker; the affected services and start date; the 90-day expiry; the renewal actor and approving parties; any change in scope and who authorised it; the discussion and publication record; the capability test for return; and the date and owner of the post-event review. The point is not to turn every field into an additional approval gate. It is to let another RIR, the affected community and an eventual reviewer distinguish a local request for help from a collective decision to continue or expand the handover.

As of the NRO’s published timeline, the draft is still moving through finalisation, with updates scheduled at upcoming RIR and ICANN meetings and approval/adoption anticipated later in Q4. The useful test for the next version is narrow: does it state whether the RIR that invokes 5.1(a) may renew; if not, what exact 5.1(b) decision is required; and which actor controls scope when the initiating route changes? Clear answers would preserve the speed sought by Version 3 while making responsibility traceable when the 90-day clock runs out.

Sources