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

[Hendrik Visage]

Dear Tshepo,

I disagree with the objection. This proposal isn't policy trying to 
shape behaviour ahead of demand — it's closing a known gap before it 
grows larger. Non-hierarchical AS-SET names allow two operators to 
register the same name, and once that happens there's no reliable way to 
tell which ASN a set actually belongs to. That ambiguity directly 
undermines IRR-based route filtering, which is a real operational and 
routing-security concern, not a theoretical one. Every flat-named AS-SET 
created under the current convention adds to the collision problem and 
makes future cleanup harder, so waiting for "sufficient demand" simply 
lets the mess compound. Far from being enforcement creep, the proposal 
is narrowly scoped: it applies only to newly created AS-SETs, doesn't 
touch route-sets or other object types, and never forces an existing 
object to be renamed. And this isn't AFRINIC inventing a mandate — 
APNIC, RIPE, ARIN, and LACNIC have all already adopted hierarchical 
AS-SET naming, which would leave AFRINIC as the only RIR without it. 
That consensus across the other four registries is exactly the "clear 
operational necessity" you're asking for.

Kind regards

---
Hendrik Visage
Director/Owner
HeViS.Co Systems t/a Envisage Cloud Solutions
hvisage at hevis.co.za
GSM/SMS/Signal: +27-84-612-5345
InstantMessenger: https://t.me/hvisage

On 17 Jul 2026, at 20:03, tshepo mavhungu wrote:

> Dear Policy Development Working Group,
>
> I would like to express my concerns regarding the proposal to 
> introduce
> hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02).
>
> I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla
> during the discussion.
>
> At first glance, this proposal appears to be a minor technical 
> enhancement.
> However, policy changes should be evaluated not only on their 
> immediate
> operational benefits, but also on whether they expand institutional
> complexity or shift the role of the registry beyond its core function.
>
> The primary role of the registry is to maintain an accurate, neutral, 
> and
> reliable resource registry and associated data infrastructure. Policy
> should focus on preserving the integrity of the ledger and enabling
> operational continuity, rather than continuously introducing new 
> structures
> that may increase dependence on registry-defined conventions.
>
> One concern is that proposals of this nature, while well-intentioned, 
> can
> contribute to what has been described as “mandate laundering”: the 
> gradual
> expansion of institutional influence through incremental policy 
> changes
> that appear administrative or technical in isolation, but collectively
> increase the scope of centralized governance over network operations 
> and
> coordination practices.
>
> The Internet’s resilience comes from minimizing unnecessary 
> dependencies
> and preserving operator autonomy. If hierarchical AS-SET naming is
> genuinely required for operational efficiency, the proposal should 
> clearly
> demonstrate that existing mechanisms are insufficient and that the 
> benefits
> outweigh the costs of additional policy complexity. Convenience alone 
> is
> not a sufficient basis for expanding registry-managed structures.
>
> This also relates to the broader “stability fallacy”: the 
> assumption that
> more structure, more policy, or more institutional mechanisms 
> necessarily
> create more stability. In many cases, long-term stability is better 
> served
> by simplicity, interoperability, and clear separation between registry
> administration and operator decision-making.
>
> The burden of proof should therefore rest with proponents to 
> demonstrate
> that this proposal addresses a concrete operational problem that 
> cannot be
> solved through existing practices, voluntary coordination, or tooling
> improvements outside the policy framework.
>
> For these reasons, I do not support the proposal in its current form 
> and
> encourage the Working Group to prioritise minimalism, operational
> continuity, and the protection of the registry’s core mandate.
>
> Kind regards,
>
> Tshepo Mavhungu
> _______________________________________________
> 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/20260718/3a9f9587/attachment-0001.html>