<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Dear RPD,</p>
<p>I'm quite confused by some of the conversation.</p>
<p>Firstly, I support the policy proposal - Hierarchical Names for
New AS-SETs.</p>
<p>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.</p>
<p>I don't recognise (as in seeing them before) the names of the
people against the proposal.</p>
<div class="moz-cite-prefix">On 2026/07/19 07:44, Noah wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEqgTWbwG+AgfU=9FneJqwwDdJ-8iCuXkHJ_SXCEWHMOnBnXww@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div>
<div><br>
</div>
<br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, 18 Jul
2026, 10:12 pm Asamkele Menzeleli, <<a
href="mailto:asamkele.menzeleli18@maharishinstitute.org"
rel="noreferrer noreferrer noreferrer noreferrer noreferrer noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">asamkele.menzeleli18@maharishinstitute.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto">Dear
Hendrik,<br style="font-size:inherit">
</div>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Hi Asamkele,</div>
<div dir="auto">
<div>
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto"><br>
</div>
<div style="font-size:inherit" dir="auto"><br
style="font-size:inherit">
I disagree with your characterization.<br
style="font-size:inherit">
<br style="font-size:inherit">
A collision between two AS-SET names is not
the same as a failure of Internet
number-resource uniqueness.</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto">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.<br
style="font-size:inherit">
<br style="font-size:inherit">
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.<br style="font-size:inherit">
<br style="font-size:inherit">
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.<br
style="font-size:inherit">
<br style="font-size:inherit">
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<br
style="font-size:inherit">
</div>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">See my response above ....</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto"><br
style="font-size:inherit">
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.<br
style="font-size:inherit">
</div>
</blockquote>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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. </div>
<div dir="auto"><br>
</div>
<div dir="auto">There was a problem and they so it fit
to fix it. Hence APNIC prop-151, a full PDP process
as an example.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto"><br
style="font-size:inherit">
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.<br style="font-size:inherit">
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
<div dir="auto"><br>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:inherit" dir="auto"><br
style="font-size:inherit">
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.<br
style="font-size:inherit">
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">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.</div>
</div>
<br>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div dir="ltr">
<div dir="ltr">
<div>Cheers,</div>
<div><b>.</b><b>/noah</b></div>
<div><b><br>
</b></div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
RPD mailing list
<a class="moz-txt-link-abbreviated" href="mailto:RPD@afrinic.net">RPD@afrinic.net</a>
<a class="moz-txt-link-freetext" href="https://lists.afrinic.net/mailman/listinfo/rpd">https://lists.afrinic.net/mailman/listinfo/rpd</a>
</pre>
</blockquote>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<p>Mark James ELKINS - Posix Systems - (South) Africa<br>
<a class="moz-txt-link-abbreviated" href="mailto:mje@posix.co.za">mje@posix.co.za</a> Tel: <a href="tel:+27826010496">+27.826010496</a><br>
For fast, reliable, low cost Internet in ZA: <a
href="https://ftth.posix.co.za" class="moz-txt-link-freetext">https://ftth.posix.co.za</a><br>
<br>
<img moz-do-not-send="false"
src="cid:part1.FdRmeLDd.QvnDVtoA@posix.co.za"
alt="Posix Systems" width="250" height="165"><img
moz-do-not-send="false"
src="cid:part2.vYG25uqt.RAf1D56O@posix.co.za"
alt="VCARD for MJ Elkins" width="164" height="164"
title="VCARD, Scan me please!"><br>
</p>
<pre class="moz-signature" cols="72">
</pre>
</div>
</body>
</html>