Summary

  • The ASO AC delivered version 3 to the NRO EC on 28 July 2026; the NRO NC published the recommended draft, redline and rationale report on 1 September 2026.
  • Section 1.3 allows enforceability before shared Implementation Procedures exist, while each RIR retains discretion over its compliance approach.
  • BTW analysis recommends a public, provision-by-provision implementation register rather than treating the label FINAL DRAFT as proof of adoption.

The document is at an important handoff point. The NRO NC, also known as the ASO AC, completed version 3 and delivered it to the NRO EC on 28 July 2026. The NRO EC said it would review the draft, coordinate with ICANN and the RIRs, and publish an updated timetable. On 1 September, the NRO NC published the recommended draft, a redline against version 2 and a rationale report.

The source text calls itself a “FINAL DRAFT”. That describes the drafting stage, not completed adoption by ICANN and all RIRs, current replacement of ICP-2 or a legal effect before formal adoption. As of the 7 September 2026 reporting freeze, the frozen source set contains neither a dated final-stage adoption timetable nor a published catalogue of adopted Implementation Procedures.

Section 1.3 is the operational fault line. It says the RIRs and ICANN may jointly develop and adopt published Implementation Procedures setting minimum requirements for provisions of the document. Procedures may not contradict or override the document. Yet, where no procedure has been adopted, each RIR retains discretion over its compliance approach, and the absence of a procedure does not prevent enforcement of the provision.

That combination creates an accountability gap without proving misconduct or current non-compliance. A substantive rule may be enforceable while the shared method for applying it remains unsettled. Section 1.4 adds that decisions follow the relevant procedures of the deciding entity, including a challenge or appeal where applicable. For AFRINIC members and Resource Holders, the practical question is therefore not only what the global text says, but who will decide, under which published process, using what evidence and with what remedy.

BTW analysis recommends that the NRO EC publish an implementation register alongside its updated timetable. The register should distinguish six states: document adoption; procedure drafting; procedure adoption; RIR-local implementation; audit readiness; and actual use. A green status in one column must not imply completion in the others.

A useful register would contain these fields: provision; procedure owner; consultation state; approval state; effective date; RIR-local implementation state; dependency; evidence link; exception; and challenge route. Suggested rows derived from the draft’s control surface include conflict-of-interest disclosures; publication and redaction rules; materiality tests; Compliance Review intake; five-year audit scope and evidence; Rehabilitation Plans; emergency-operator qualification; continuity data handoff; Transition Plans; and appeal procedures.

These are recommended monitoring rows, not a claim that separate procedures are legally required for every item. They make visible the difference between a rule appearing in the document and an operational control being published, implemented, tested and used.

The draft’s version-three controls make the distinction consequential. It changes recognition to a two-thirds RIR support threshold, adds conflict-of-interest disclosure and publication of assessments and rationales, and gives ICANN specified review and decision roles. It provides for a regular audit at least once every five years. A Compliance Review may be requested by a majority of the other RIRs, by the RIR itself, or by the lesser of 15% or 1,000 of the subject RIR’s members, subject to materiality and prior-remedy requirements.

If an Audit or Compliance Review finds non-compliance, ICANN must publish findings and, where appropriate, work with the RIRs on a Rehabilitation Plan, then verify and publish whether remediation succeeded. The document also describes a Temporary Emergency Continuity Arrangement for an affected RIR’s services. The affected RIR may initiate the arrangement for its own services. It may be initiated or renewed by ICANN and two-thirds of the other RIRs after discussion where reasonably possible, is limited to 90 days unless renewed, and carries publication and community-engagement requirements.

Derecognition is framed as a last resort after a reasonable opportunity to remedy material non-compliance, with two-thirds support from the other RIRs required before ICANN may approve it.

The NRO NC says version 3 addresses the main concerns raised in consultation. That is the drafting body’s account, not an independent finding that every concern was resolved. Its rationale report describes Compliance Review as more lightweight and faster than a full audit and says safeguards are intended to prevent misuse. It also says the emergency-threshold change is intended to support quicker response while the 90-day limit prevents temporary operation from becoming the default.

The frozen evidence does not establish which Implementation Procedures already exist privately or are being drafted internally. It also does not establish how ICANN or the RIRs will interpret terms such as “material”, “reasonable”, “promptly” or “where reasonably possible”, identify a future auditor or Temporary Emergency Operator, or show whether any RIR would pass an audit or face a review. Those questions belong in the register as unknowns, not as assumed outcomes.

For resource holders, the register would turn a governance handoff into an observable chain of responsibility. It would show whether a safeguard is merely drafted, approved globally, implemented locally, audit-ready or actually invoked. That is the missing operational bridge between a stronger text and accountable practice.