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

[Mark Elkins]

Dear RPD,

I'm quite confused by some of the conversation.

Firstly, I support the policy proposal - Hierarchical Names for New AS-SETs.

What I see is that people who have been in the Industry for many years 
and who's names are well known to me (Hendrik, Noah, Seun, Nishal)  all 
support the proposal - as have the other four RIR's. They are all in the 
business of BGP - etc. They approve of the proposal and wouldn't do that 
if it was going to greatly complicate their lives.

I don't recognise (as in seeing them before) the names of the people 
against the proposal.

On 2026/07/19 07:44, Noah wrote:
>
>
>
> 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*
> *
> *
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

Posix SystemsVCARD for MJ Elkins
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a9da10ef/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a9da10ef/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a9da10ef/attachment-0001.png>