<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body><div style="font-family: sans-serif;"><div class="markdown" style="white-space: normal;">
<p dir="auto">Dear Tshepo,</p>
<p dir="auto">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.</p>
<p dir="auto">Kind regards</p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">Hendrik Visage<br>
Director/Owner<br>
HeViS.Co Systems t/a Envisage Cloud Solutions<br>
<a href="mailto:hvisage@hevis.co.za" style="color: #3983C4;">hvisage@hevis.co.za</a><br>
GSM/SMS/Signal: +27-84-612-5345<br>
InstantMessenger: <a href="https://t.me/hvisage" style="color: #3983C4;">https://t.me/hvisage</a></p>
<p dir="auto">On 17 Jul 2026, at 20:03, tshepo mavhungu wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Dear Policy Development Working Group,</p>
<p dir="auto">I would like to express my concerns regarding the proposal to introduce<br>
hierarchical naming for new AS-SETs (AFPUB-2026-ASN-001-DRAFT02).</p>
<p dir="auto">I agree with the concerns raised by Fundiswa, Thandeka, and Nonhlanhla<br>
during the discussion.</p>
<p dir="auto">At first glance, this proposal appears to be a minor technical enhancement.<br>
However, policy changes should be evaluated not only on their immediate<br>
operational benefits, but also on whether they expand institutional<br>
complexity or shift the role of the registry beyond its core function.</p>
<p dir="auto">The primary role of the registry is to maintain an accurate, neutral, and<br>
reliable resource registry and associated data infrastructure. Policy<br>
should focus on preserving the integrity of the ledger and enabling<br>
operational continuity, rather than continuously introducing new structures<br>
that may increase dependence on registry-defined conventions.</p>
<p dir="auto">One concern is that proposals of this nature, while well-intentioned, can<br>
contribute to what has been described as “mandate laundering”: the gradual<br>
expansion of institutional influence through incremental policy changes<br>
that appear administrative or technical in isolation, but collectively<br>
increase the scope of centralized governance over network operations and<br>
coordination practices.</p>
<p dir="auto">The Internet’s resilience comes from minimizing unnecessary dependencies<br>
and preserving operator autonomy. If hierarchical AS-SET naming is<br>
genuinely required for operational efficiency, the proposal should clearly<br>
demonstrate that existing mechanisms are insufficient and that the benefits<br>
outweigh the costs of additional policy complexity. Convenience alone is<br>
not a sufficient basis for expanding registry-managed structures.</p>
<p dir="auto">This also relates to the broader “stability fallacy”: the assumption that<br>
more structure, more policy, or more institutional mechanisms necessarily<br>
create more stability. In many cases, long-term stability is better served<br>
by simplicity, interoperability, and clear separation between registry<br>
administration and operator decision-making.</p>
<p dir="auto">The burden of proof should therefore rest with proponents to demonstrate<br>
that this proposal addresses a concrete operational problem that cannot be<br>
solved through existing practices, voluntary coordination, or tooling<br>
improvements outside the policy framework.</p>
<p dir="auto">For these reasons, I do not support the proposal in its current form and<br>
encourage the Working Group to prioritise minimalism, operational<br>
continuity, and the protection of the registry’s core mandate.</p>
<p dir="auto">Kind regards,</p>
<p dir="auto">Tshepo Mavhungu</p>
<hr style="border: 0; height: 1px; background: #333; background-image: linear-gradient(to right, #ccc, #333, #ccc);">
<p dir="auto">RPD mailing list<br>
<a href="mailto:RPD@afrinic.net" style="color: #777777;">RPD@afrinic.net</a><br>
<a href="https://lists.afrinic.net/mailman/listinfo/rpd" style="color: #777777;">https://lists.afrinic.net/mailman/listinfo/rpd</a></p>
</blockquote>
</div>
</div>
</body>
</html>