[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) and Amendment of Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02)

[Nia Petronella]

Dear Colleagues,

I do *not* support adoption of this proposal.

The proposal appears technically modest, but it reflects a broader pattern
that AFRINIC should be moving away from, not reinforcing. Every new policy
that expands registry-defined objects, procedures, or institutional scope
should first answer a simple question: *does this protect uniqueness, or
does it expand the registry's governance surface?*

A registry exists to maintain accurate records and protect uniqueness. It
may record. It may coordinate. It may protect uniqueness. It may not rule.
Once policy begins creating additional administrative structures that are
not strictly required for interoperability, we should ask whether we are
solving an Internet problem or an institutional one.

This proposal also illustrates what Lu Heng describes as the *Policy Mirror*.
The issue is not hierarchical AS-SET names themselves, but the continuing
assumption that every operational practice should be standardized through
registry policy rather than left to voluntary operator adoption. Running
networks—not policy manuals—should determine what survives. If hierarchical
naming provides sufficient operational value, operators will naturally
deploy it without requiring another layer of institutional governance.

Furthermore, AFRINIC should be reducing policy complexity rather than
increasing it. *Running-Code Primacy* requires that policy remain the
minimum necessary to preserve interoperability and operational continuity.
Every additional policy object increases long-term maintenance,
interpretation, and enforcement costs while offering limited benefit to the
stability of the Internet itself. The common layer should remain thin.

Finally, rough consensus should not be mistaken for proof that additional
governance is desirable. A mailing list is not a legislature, and community
discussion should not automatically become permanent policy. Before
adopting any proposal, we should first ask whether failure to adopt would
actually threaten uniqueness, interoperability, or operational continuity.
If the answer is no, then the proposal belongs in operational best
practice, not in mandatory registry policy.

For these reasons, I oppose adoption.


BR,

Nonhlanhla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260717/34e3f4a7/attachment.html>