[rpd] [Last Call] Draft Policy Proposal - Hierarchical Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)

[Noah]

On Sat, 18 Jul 2026, 10:12 pm Asamkele Menzeleli, <
asamkele.menzeleli18 at maharishinstitute.org> wrote:

> Dear Hendrik,
>

Hi Asamkele,

>
>
> I disagree with your characterization.
>
> A collision between two AS-SET names is not the same as a failure of
> Internet number-resource uniqueness.
>

So, while you are somewhat correct on that very narrow point, its still
irrelevant imho. The issue is namespace integrity and authorization for
policy objects in a globally mirrored system. RFC 2622 hierarchical naming
was invented exactly to solve this. Collisions break automated tools that
networks rely on for prefix filtering and I mean really technically breaks
....FYI


An AS-SET is an operational routing-policy object. Confusing the naming
> convention of that object with the uniqueness of the underlying number
> resource expands the meaning of “uniqueness” far beyond its proper
> technical scope.
>
> The fact that two operators may choose the same flat label may justify
> better tooling, clearer warnings, stronger validation or voluntary
> hierarchical naming. It does not automatically justify a mandatory policy
> rule.
>
> That distinction is precisely the concern I raised. Institutional
> authority often expands by redefining a useful administrative preference as
> a technical necessity. Once every data-quality issue is described as a
> uniqueness failure, there is effectively no limit to what may be brought
> into mandatory registry policy.
>
> The proposal’s limited scope does not answer that concern. A new
> enforcement power does not cease to be enforcement merely because it
> applies prospectively or begins with one object type. The correct test is
> whether the rule is indispensable to preserving the operation of running
> networks, and whether a less restrictive mechanism cannot achieve the same
> outcome
>

See my response above ....



> You also repeat that the other four RIRs have implemented hierarchical
> naming. That demonstrates institutional adoption elsewhere. It does not
> demonstrate that AFRINIC operators have authorized the same rule, that
> actual routing failures in this region require it, or that voluntary and
> technical alternatives are inadequate. Four registries making the same
> choice is not a substitute for evidence.
>


Firstly, the AFRINIC service region is not an isolated island. Other RIRs
so the need to implement this after experiencing the same cross-IRR
collision and perhaps incidents of unauthorized creation problems.

There was a problem and they so it fit to fix it. Hence APNIC prop-151, a
full PDP process as an example.

Therefore imho, It is a broader convergence on a technical solution to a
shared defect in the IRR ecosystem, not arbitrary uniformity. AFRINIC
operators already benefit from that very same protection the other RIR have
put in place and we not doing it is accepting an existing bug is the system
to continue existing hence the PDWG support you are seeing from technical
community.


> A registry should record operational reality accurately and provide
> operators with tools to manage routing information safely. It should not
> turn every preferred convention into mandatory governance merely because
> uniformity looks tidy from the registry side.
>

Well there is only so much a registry can do. We the community have been
empowered to develop policies that support the operations aspects of the
RIR.

When voluntary adoption + guidance has continued to demonstrably failed for
years (non-hierarchical sets are still being created), and when the failure
mode enables unauthorized objects that can disrupt routing, enforcement at
creation time becomes the proportionate response. This is exactly what
RIPE, APNIC, and others concluded.



> My objection therefore remains. The proposal has not shown that compulsory
> hierarchical naming is necessary to protect number-resource uniqueness, nor
> that the registry should extend its mandatory policy authority into this
> area.
>

Actually the risk here is global and probabilistic. And I say so, because
by not resolving IRRs merge in all five registry databases, a colliding or
squatted AS-SET created in AFRINIC db can affect networks widely (and vice
versa). Waiting for an AFRINIC-specific outage before acting is reactive
rather than responsible stewardship of the registry and the community is
already empowered to always look out for solutions to better RIR operations
some of which are policy driven.

Cheers,
*.**/noah*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/f21e6edf/attachment-0001.html>