<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">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 dir="auto"></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"></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"></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"></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"></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 dir="auto"></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>