<!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 Asamkele,<br>
The distinction you draw doesn't survive contact with how the objects actually work: an AS-SET name is not merely a label, it is the authorization anchor for the object. Under RFC 2622 hierarchical naming, the leading AS number binds the set to a resource the registry has already uniquely assigned, so only the maintainer of that ASN can create or modify it — proof of control, which you agree is core registry function, is derived directly from the name. A flat name has no such binding, which means the registry is accepting objects it cannot attribute to any resource holder; that is not a data-quality preference, it is an authorization gap in the registry's own database. This is also why voluntary naming cannot solve it: hierarchy protects you only if the flat namespace is closed, because as long as anyone can create AS-EXAMPLE, your careful use of AS65000:AS-EXAMPLE does nothing to stop a third party from registering a colliding or shadowing set that expands into your customer cone. The harm is concrete and regional in effect regardless of where the query originates — bgpq4, IRRToolSet and similar expand AS-SET names, so an ambiguous name yields a prefix-list that either admits prefixes the operator never authorized or omits ones it did, and the resulting leak or blackhole lands on AFRINIC networks. Better tooling and warnings cannot close this, because the ambiguity exists in the data the tooling consumes, not in the tooling itself. As for scope: rejecting the creation of unauthorizable objects is the same function the registry already performs when it refuses an unauthenticated route object — it is the existing mandate applied consistently, not a new one, and applying it prospectively to a single object type is the least restrictive form in which it can achieve the outcome at all.<br>
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 18 Jul 2026, at 21:05, Asamkele Menzeleli wrote:</p>
<blockquote style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;">
<p dir="auto">Dear Hendrik,</p>
<p dir="auto">I disagree with your characterization.</p>
<p dir="auto">A collision between two AS-SET names is not the same as a failure of<br>
Internet number-resource uniqueness. The uniqueness function of the<br>
registry concerns ASNs, prefixes, proof of control and accurate<br>
registration of those resources. An AS-SET is an operational routing-policy<br>
object. Confusing the naming convention of that object with the uniqueness<br>
of the underlying number resource expands the meaning of “uniqueness” far<br>
beyond its proper technical scope.</p>
<p dir="auto">The fact that two operators may choose the same flat label may justify<br>
better tooling, clearer warnings, stronger validation or voluntary<br>
hierarchical naming. It does not automatically justify a mandatory policy<br>
rule.</p>
<p dir="auto">That distinction is precisely the concern I raised. Institutional authority<br>
often expands by redefining a useful administrative preference as a<br>
technical necessity. Once every data-quality issue is described as a<br>
uniqueness failure, there is effectively no limit to what may be brought<br>
into mandatory registry policy.</p>
<p dir="auto">The proposal’s limited scope does not answer that concern. A new<br>
enforcement power does not cease to be enforcement merely because it<br>
applies prospectively or begins with one object type. The correct test is<br>
whether the rule is indispensable to preserving the operation of running<br>
networks, and whether a less restrictive mechanism cannot achieve the same<br>
outcome.</p>
<p dir="auto">You also repeat that the other four RIRs have implemented hierarchical<br>
naming. That demonstrates institutional adoption elsewhere. It does not<br>
demonstrate that AFRINIC operators have authorized the same rule, that<br>
actual routing failures in this region require it, or that voluntary and<br>
technical alternatives are inadequate. Four registries making the same<br>
choice is not a substitute for evidence.</p>
<p dir="auto">A registry should record operational reality accurately and provide<br>
operators with tools to manage routing information safely. It should not<br>
turn every preferred convention into mandatory governance merely because<br>
uniformity looks tidy from the registry side.</p>
<p dir="auto">My objection therefore remains. The proposal has not shown that compulsory<br>
hierarchical naming is necessary to protect number-resource uniqueness, nor<br>
that the registry should extend its mandatory policy authority into this<br>
area.</p>
<p dir="auto">Regards,<br>
Asamkele Menzeleli</p>
</blockquote>
</div>
</div>
</body>
</html>