[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)

[Seun Ojedeji]

Hello Nia,

The registry administers number resources through policies that govern it.
To your question* "...does it expand the registry's governance surface?" *no
it doesn't, the proposal once ratified will serve as one of the policies
that helps the RIR fulfil its role.

Regards

On Fri, 17 Jul 2026 at 10:40, Nia Petronella <
nonhlanhlapetronella85 at gmail.com> wrote:

> 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
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
>


-- 
------------------------------------------------------------------------


*Seun Ojedeji,*

Bringing another down does not take you up - think about your action!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260717/d1959ce4/attachment.html>