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

Hello Seun,

That response illustrates precisely the concern.

Saying that a proposal “helps the RIR fulfil its role” does not answer
whether the proposal expands that role. It merely assumes the scope of the
role in advance and then uses policy adoption to validate the assumption.

That is circular.

The registry’s original technical function is narrow: preserve uniqueness,
maintain accurate records, support contactability, record changes of
control, and protect operational continuity. Those functions justify a
registry. They do not create a general mandate to regulate every practice
that can be attached to a registry object.

A policy does not become legitimate merely because the registry can
administer it. Nor does ratification transform an administrative preference
into a technical necessity. Otherwise, there is no limiting principle. Any
proposal can be said to “help the RIR fulfil its role,” provided the role
is continuously redefined by the policies the RIR later enforces.

That is mandate laundering.

A narrow coordination function is passed through the language of policy,
consensus, and community until it re-emerges as institutional authority.
The process then points to its own output as proof that the authority
existed all along.

But policy procedure cannot manufacture mandate.

A meeting is not a legislature. Participation is not authorization. Rough
consensus does not give a registry an unlimited governance surface over
operators, routing practice, commercial arrangements, naming conventions,
or future implementation choices.

The proper question is not whether the proposal can be administered by the
RIR. Almost anything can be administered once enough procedure is created
around it.

The proper question is: what technical invariant requires this rule to be
mandatory?

Does it protect uniqueness?

Does it prevent duplicate registration?

Does it preserve registry accuracy?

Does it protect security integrity?

Does it preserve operational continuity?

If it does not, then it is not a necessary registry function. It is
institutional preference being converted into enforceable policy.

There is also an important distinction between recording a practice and
governing it. A registry may accurately record AS-SET information. It may
provide technical formats and interoperable publication mechanisms. It
should not assume that maintaining the database gives it authority to
prescribe every naming structure used by operators.

The registry should describe operational reality, not manufacture it
through policy and then enforce obedience through control of the registry
layer.

So yes, this proposal does expand the governance surface. It does so by
converting a naming convention into a policy obligation and then placing
the registry in the position of interpreting, administering, and enforcing
that obligation.

Calling that “fulfilling the RIR’s role” does not resolve the objection.

It proves it.

Regards,

Nonhlanhla

On Fri, 17 Jul 2026, 6:24 pm Seun Ojedeji <seun.ojedeji at gmail.com> wrote:

> 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/cf9c5d23/attachment-0001.html>