Summary

  • AFPUB-2026-ASN-001-DRAFT02 would require hierarchical names for newly created AFRINIC AS-SETs while preserving existing flat objects and edits.
  • Restoring a deleted flat object is different from preserving, editing or creating an object, and the proposal leaves the proof and approval boundary unspecified.
  • AFRINIC staff warn that restoration could leave an operational side door; BTW analysis recommends a case-level restoration receipt and aggregate, non-sensitive reporting.

The proposal is a forward rule, not a cleanup of AFRINIC’s existing flat-name corpus. It would apply when an AS-SET is created in the AFRINIC WHOIS database. RFC 2622 describes hierarchical set names as colon-separated components that may begin with an ASN; its namespace-control rule gives the maintainer of the parent object control over creation of a child name.

The proposal deliberately protects installed legacy state. Existing non-hierarchical AS-SETs must not be renamed, may continue under their current names and may be edited without renaming. The stated rationale is that mass renaming would create large inconsistencies and that there is no reliable programmatic way to identify the ASN associated with every existing AFRINIC AS-SET. That protection also preserves routing-policy references.

Those operations are not interchangeable. Preserving an existing object leaves its identity in place. Editing changes permitted content without changing the name. Creating a new object establishes a new record under the proposed creation rule. Restoring a deleted object attempts to bring back a previously installed identity after deletion. The last operation therefore needs evidence about what existed, what happened and why continuity is necessary.

The proposal’s mandatory example is the restoration of a non-hierarchical AS-SET deleted by mistake. AFRINIC staff’s proposed wording says an exception may be granted where necessary and that AFRINIC shall document the reason. Staff separately warn that recalling a deleted flat object could introduce an operational loophole and reduce the policy’s effectiveness. At AFRINIC 37, the minutes record staff describing this as leaving a side door open. They also record that deletion requires authentication against the maintainer.

The frozen evidence does not specify how accidental deletion would be proved, how long restoration could remain available, who would approve it, what fields the record would contain, whether repeat restorations would be allowed or whether aggregate use would be reported. Nor does it identify an actual restoration case.

The public AFRINIC IRR guide documents portal and WHOIS-web creation and maintainer protection. The evidence packet does not test those production paths and does not show that the proposed restriction is active. The proposal identifies WHOIS and MyAFRINIC/IRR interfaces as affected systems and says server-side and exposed creation-form or API validation should be used. Staff say implementation would be prioritised after MyAFRINIC v2, a conditional plan rather than evidence of implementation.

BTW analysis: a restoration receipt should record the prior AS-SET name and hash; deletion timestamp and authenticated actor; evidence of accidental deletion; affected routing-policy references; alternatives considered; approving reviewer; decision time; an expiry or migration condition; and a closure record. It should distinguish continuity from an invitation to keep reopening flat namespace state.

A second BTW analysis is aggregate exception reporting: counts by disposition and perhaps broad timing or migration outcome, without maintainer secrets or sensitive routing configuration. Such reporting is not an existing AFRINIC product or adopted requirement.

Publication note: Published is the scheduled editorial date, 7 September 2026, in Asia/Shanghai. The actual server publication time is unset.

Sources

  1. https://www.afrinic.net/policy-proposals.html
  2. https://www.afrinic.net/afpub-2026-asn-001-draft02
  3. https://www.afrinic.net/ppm-afrinic-37.html
  4. https://www.rfc-editor.org/rfc/rfc2622.html
  5. https://afrinic.net/irr-guide