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

[Jaco Kroon]

Hi,

Please allow me to be blatantly blunt:

The only possible reason I can imagine to resist this proposal is 
because you don't want people to use Hierarchical Names, leaving them 
vulnerable to IRR collision attacks, in order to enable yourself or a 
related party to execute such a collision attack against them.  Either 
that or you're resisting change for the sake of resisting change.

The problem is, it's usually not the vulnerable party that suffers the 
damages, it's their peers, service providers and customers.

I beg you Mphoentle, as well as Tshepo, Paulo, Nthabiesng, Thandeka, 
Thulisile, Nia, Asamkele, Nonhlanhla and probably others I've missed now 
please stop this.  Others call this astroturfing. Just because a bunch 
of you repeat the same rhetoric, not grounded in actual technical fact 
or sound reasoning, does not make it true, reasonable or sensible.  If 
you want to object, please clarify to us from a technical and 
operational perspective how this policy causes harm (ie, as Nishal said 
- creates operational problems - so that we can address that).

It has been shown, and is well know, that Hierarchical Names helps avoid 
inter-RIR naming collissions, this preventing a set of known attacks (at 
least one of our upstreams was collided previously, causing measurable 
harm to us - this policy, if implemented from day one, would have 
prevented that).  This does not in any way add additional centralised 
control - you can choose to use these objects to help protect you, your 
customers, as well as your providers, or not.  But I highly recommend 
you do.  This policy, does in fact, not actually change anything other 
than force those that choose to use the mechanism to not make themselves 
vulnerable to known naming collision attacks.  In other words - this 
policy solves actual real-world problem for real network operators.  If 
that can be done in a better way - please speak up and show us how, 
rather than just merely objecting.

Better tooling as some have implied does not stop the problem. One can 
(for bgpq* at least) say to specifically look at say AFRINIC::ULS - but 
fixing the root cause of the problem should be preferred over requiring 
all tooling to work around the problem. Which is what this policy does.

The same goes for every other objection to this proposal.  It feels like 
the whole AS0 situation all over again.  Those of us who operated actual 
networks has existing operational problems which this, and policies such 
as others being resisted currently, as well as the previously mentioned 
AS0 policy, helps address. This isn't about centralising control.  This 
is about protecting resources and making the Internet a better and safer 
place for all.

These policies helps to make the internet a safer place for all.

Kind regards,
Jaco Kroon

On 2026/07/17 21:36, Mphoentle Mokheseng via RPD wrote:

> Dear PDWG Chairs,
>
> I object to AFPUB-2026-ASN-001-DRAFT02.
>
> The Internet has always succeeded by minimizing the amount of 
> centralized authority required for independent networks to 
> interoperate. Coordination is necessary. Governance beyond what 
> coordination requires is not.
>
> This proposal may appear modest, but it reflects a broader trend that 
> deserves scrutiny. We increasingly treat every operational preference 
> as something that must be standardized through policy simply because 
> the registry is capable of administering it. That reverses the proper 
> relationship between operations and policy.
>
> Policy should emerge from established operational reality. It should 
> not be used to manufacture it.
>
> The burden is on the proposer to demonstrate that an existing 
> technical deficiency cannot be addressed without creating a new policy 
> obligation. I do not believe that burden has been met. No compelling 
> evidence has been presented that current AS-SET naming practices 
> threaten uniqueness, registry integrity, interoperability, or the 
> stable operation of the Internet.
>
> The fact that a naming convention may be desirable does not make it an 
> appropriate subject for mandatory registry policy.
>
> Every additional policy expands the registry's sphere of 
> interpretation and administration. Individually these expansions 
> appear harmless. Collectively they normalize the idea that the 
> registry should increasingly prescribe operational behaviour rather 
> than simply coordinate shared technical resources.
>
> That is a direction we should resist.
>
> The registry's legitimacy comes from performing a narrowly defined 
> technical function exceptionally well, not from continuously enlarging 
> its policy surface. We should preserve that distinction. Institutions 
> are strongest when they exercise only the authority that is 
> demonstrably necessary, and no more.
>
> For these reasons, I object to AFPUB-2026-ASN-001-DRAFT02.
>
> Kind regards,
> Mphoentle
> Disclaimer This email and the information contained herein are Advtech 
> Ltd confidential and are protected by law. Please navigate to our 
> website for more information https://www.groupadvtech.com. Use of this 
> information or this email by any person for any purposes other than 
> that for which it is intended is prohibited and may result in civil 
> and/or criminal liability. This email is not to be shared with any 3rd 
> parties not included within this email, without the written consent of 
> its Author. If you have received this message in error, please notify 
> Advtech immediately, telephone number +27 11 676 8000. Advtech leads 
> the private sector in the fields of education and resourcing, 
> contributing meaningfully towards the sustainable development of human 
> capacity in South Africa.
>
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260720/68c27d2f/attachment-0001.html>