<div dir="auto">Dear Hendrik,<div dir="auto"><br></div><div dir="auto">I agree with Gugu, Tshepo, and Asamkele, and I remain firmly opposed to this proposal.</div><div dir="auto"><br></div><div dir="auto">Your argument proves that mandatory hierarchical naming can close one path to future flat-name collisions. It does not prove that the proposal secures the routing information consumed by operators.</div><div dir="auto"><br></div><div dir="auto">That difference is fundamental.</div><div dir="auto"><br></div><div dir="auto">A hierarchical name authenticates the maintainer permitted to create the object under an ASN. It does not authenticate every member placed inside that object. It does not prove that the represented customer cone is complete, current, or authorised. It does not prevent an authorised maintainer from publishing stale, excessive, mistaken, or misleading membership.</div><div dir="auto"><br></div><div dir="auto">The tools you cite expand the contents of an AS-SET. They do not merely validate the parent ASN in its name. Closing the namespace may improve provenance, but it does not make the expanded data true.</div><div dir="auto"><br></div><div dir="auto">The proposal is therefore being credited with a security outcome it cannot deliver. It reduces one ambiguity while leaving the central semantic risk intact. A partial control should be described as a partial control, not elevated into a universal protection merely because it is easy to enforce at object creation.</div><div dir="auto"><br></div><div dir="auto">You also argue that AFRINIC would become the weak link because other RIRs have adopted the rule. That is still institutional convergence being used as a substitute for proving necessity. A globally consumed system requires explicit source identity, deterministic validation, trustworthy provenance, and local rejection of unsafe data. It does not follow that every source must impose the same mandatory naming convention through registry policy.</div><div dir="auto"><br></div><div dir="auto">A consumer that merges multiple IRR sources and silently treats an ambiguous name as authoritative has made a validation decision. That design choice cannot simply be transferred upward and converted into a new power for the registry. Unsafe consumption is not cured only by restricting production.</div><div dir="auto"><br></div><div dir="auto">Nor is “new objects only” proof that this is the least restrictive solution. It describes the proposal’s temporal scope. It does not demonstrate that source-qualified queries, collision detection, provenance-aware tooling, ambiguity rejection, or stronger object-content validation are technically inadequate.</div><div dir="auto"><br></div><div dir="auto">The minimum intervention is not automatically the smallest rule the registry can enforce. It is the least coercive mechanism that protects the actual invariant. That analysis has not been completed.</div><div dir="auto"><br></div><div dir="auto">The broader concern is precisely this pattern: a technical inconvenience is identified, one centralised remedy is proposed, and then the existence of the inconvenience is treated as authority for compulsion. The registry’s role expands one apparently narrow rule at a time. No one announces enforcement creep. It arrives dressed as data hygiene.</div><div dir="auto"><br></div><div dir="auto">A registry may maintain accurate records, expose provenance, warn about collisions, and support safer tooling. It should not pretend that controlling the name of a container guarantees the accuracy of what the container says.</div><div dir="auto"><br></div><div dir="auto">Responding to objections individually is not itself the problem. The problem is that the same institutional answer is being repeated without resolving the same substantive objection: the proposal authenticates object creation but does not validate object content, and its supporters have not shown why registry compulsion is the minimum necessary response.</div><div dir="auto"><br></div><div dir="auto">The common layer must remain thin. It should protect what running networks objectively require, not every convention that an institution can enforce.</div><div dir="auto"><br></div><div dir="auto">For these reasons, I support Gugu, Tshepo, and Asamkele, and I maintain my strong opposition to AFPUB-2026-ASN-001-DRAFT02.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonhlanhla</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 19 Jul 2026, 6:14 am Hendrik Visage <<a href="mailto:hvisage@hevis.co.za">hvisage@hevis.co.za</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear colleagues,<br>
The point about voluntary naming is where the argument breaks down. Hierarchical naming only protects you if the namespace is closed — if flat names remain creatable, any third party can still register a name that collides with or shadows yours, and your voluntary good behaviour does nothing to stop it. That is why every other RIR made it mandatory rather than advisory: the protection is only real when it's universal. On measurable harm: tools like bgpq4 expand AS-SET names, not ASNs, so when a name is ambiguous the generated prefix-filter can silently include the wrong prefixes or drop the right ones. That is a routing outcome, not a labelling aesthetic — and it is precisely the "accurate routing information" you say the registry should support. On least-restrictive: this proposal already is the minimum — new objects only, no renaming, no other set types, no ongoing registry discretion. It is hard to describe a narrower intervention that still closes the namespace. And the point about other RIRs isn't an appeal to conformity; IRR data is consumed globally as a single namespace by operators who query multiple sources, so AFRINIC remaining the one registry that permits flat names doesn't preserve our independence — it just makes our data the weak link in everyone else's filters. Finally, responding to objections individually is engaging with them on their merits; that is what the process asks for.<br>
Regards<br>
<br>
On 18 Jul 2026, at 21:49, Nia Petronella wrote:<br>
<br>
> Dear PDWG,<br>
><br>
> I agree with Asamkele, Gugu, and Tshepo, and I remain opposed to this<br>
> proposal.<br>
><br>
> Responding to objectors one by one does not resolve the common concern they<br>
> have raised. A collision between AS-SET labels is not a failure of ASN or<br>
> prefix uniqueness, and repeating that characterization does not make it<br>
> technically correct.<br>
><br>
> The proposal still has not demonstrated measurable operational harm, why<br>
> voluntary hierarchical naming is insufficient, or why mandatory registry<br>
> intervention is the least restrictive solution. Adoption by other RIRs is<br>
> relevant, but institutional uniformity is not proof of technical necessity.<br>
><br>
> A policy process should examine objections on their merits, not treat<br>
> repeated disagreement as something to be individually overcome. The<br>
> registry should support accurate routing information without converting<br>
> every preferred convention into compulsory policy.<br>
><br>
> I therefore support the objections already raised and maintain my<br>
> opposition.<br>
><br>
> Regards,<br>
> Nonhlanhla<br>
><br>
> On Sat, 18 Jul 2026, 9:46 pm <<a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a>> wrote:<br>
><br>
>> Send RPD mailing list submissions to<br>
>>         <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>><br>
>> To subscribe or unsubscribe via the World Wide Web, visit<br>
>>        <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>> or, via email, send a message with subject or body 'help' to<br>
>>         <a href="mailto:rpd-request@afrinic.net" target="_blank" rel="noreferrer">rpd-request@afrinic.net</a><br>
>><br>
>> You can reach the person managing the list at<br>
>>         <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>><br>
>> When replying, please edit your Subject line so it is more specific<br>
>> than "Re: Contents of RPD digest..."<br>
>><br>
>><br>
>> Today's Topics:<br>
>><br>
>>    1. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Hendrik Visage)<br>
>>    2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Asamkele Menzeleli)<br>
>>    3. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
>>       for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Gugu Dhlamini)<br>
>><br>
>><br>
>> ----------------------------------------------------------------------<br>
>><br>
>> Message: 1<br>
>> Date: Sat, 18 Jul 2026 20:28:16 +0200<br>
>> From: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>><br>
>> To: Asamkele Menzeleli <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>><br>
>> Cc: <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a>, <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID: <<a href="mailto:6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66@hevis.co.za" target="_blank" rel="noreferrer">6F54C5B9-4C90-42F4-ACFD-6E4C57F5BD66@hevis.co.za</a>><br>
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
>><br>
>> Hello Asamkele,<br>
>> Respectfully, this proposal does exactly what you're asking for ? it<br>
>> maintains uniqueness. Flat AS-SET names can be registered by anyone, so<br>
>> two operators can create the same name and there is no way to tell<br>
>> afterwards which ASN it belongs to. That is a uniqueness failure in the<br>
>> registry's own data, and fixing it is squarely within the mandate you<br>
>> describe, not an expansion of it. The proposal adds no governance layer:<br>
>> it applies only to newly created AS-SETs, leaves existing objects<br>
>> untouched, and doesn't extend to route-sets or anything else. And the<br>
>> operational necessity is already demonstrated ? APNIC, RIPE, ARIN, and<br>
>> LACNIC have all implemented hierarchical AS-SET naming, which would<br>
>> leave AFRINIC as the only registry whose IRR data still permits name<br>
>> collisions.<br>
>> Regards<br>
>><br>
>> ---<br>
>> Hendrik Visage<br>
>> Director/Owner<br>
>> HeViS.Co Systems t/a Envisage Cloud Solutions<br>
>> <a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a><br>
>> GSM/SMS/Signal: +27-84-612-5345<br>
>> InstantMessenger: <a href="https://t.me/hvisage" rel="noreferrer noreferrer" target="_blank">https://t.me/hvisage</a><br>
>><br>
>> On 17 Jul 2026, at 19:26, Asamkele Menzeleli wrote:<br>
>><br>
>>> Hello everyone,<br>
>>><br>
>>> I object to this proposal.<br>
>>><br>
>>> I also agree with Nonhlanhla's point regarding mandate laundering. We<br>
>>> should be careful not to confuse policy development with expanding<br>
>>> institutional authority.<br>
>>><br>
>>> Policies should reflect demonstrated operational realities and<br>
>>> technical<br>
>>> necessity. They should not become governance mechanisms that gradually<br>
>>> enlarge the registry's role beyond maintaining uniqueness, accurate<br>
>>> records, and operational coordination.<br>
>>><br>
>>> A registry should record reality, not create new layers of governance<br>
>>> through policy.<br>
>>><br>
>>> Regards,<br>
>>> Asamkele Menzeleli<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/cd333640/attachment-0001.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 2<br>
>> Date: Sat, 18 Jul 2026 21:05:38 +0200<br>
>> From: Asamkele Menzeleli <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>><br>
>> To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
>> Cc: <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID:<br>
>>         <CAP3o3_aaSmMp7onNPHESjeoAScNZCZbg_FFjed=<br>
>> <a href="mailto:Yxp%2BMhGJFpQ@mail.gmail.com" target="_blank" rel="noreferrer">Yxp+MhGJFpQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Dear Hendrik,<br>
>><br>
>> I disagree with your characterization.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> Regards,<br>
>> Asamkele Menzeleli<br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/e46cf6c9/attachment-0001.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Message: 3<br>
>> Date: Sat, 18 Jul 2026 21:45:03 +0200<br>
>> From: Gugu Dhlamini <<a href="mailto:gugudhlamini343@gmail.com" target="_blank" rel="noreferrer">gugudhlamini343@gmail.com</a>><br>
>> To: "<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>"<br>
>>         <<a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>>,  "<br>
>> <a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>"<br>
>>         <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>>, <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>, <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
>> Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
>>         Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
>> Message-ID:<br>
>>         <<br>
>> <a href="mailto:CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w@mail.gmail.com" target="_blank" rel="noreferrer">CADMrvbPw1Dyu7JU9unFWz4zTZSd4QGQdMup_ibDd9nKcWwuP-w@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset="utf-8"<br>
>><br>
>> Dear PDWG,<br>
>><br>
>> I agree with Asamkele and disagree with Hendrik?s perspective.<br>
>><br>
>> This is substantially the same argument Hendrik made in response to Tshepo:<br>
>> that because a naming collision can occur, the issue must therefore be<br>
>> treated as a failure of registry uniqueness and made subject to mandatory<br>
>> policy. That conclusion does not follow.<br>
>><br>
>> A collision between AS-SET labels is not the same as duplicate allocation<br>
>> of an ASN or IP prefix. The underlying number resources remain unique. What<br>
>> is being discussed is the naming and interpretation of an operational<br>
>> routing object. That may justify better tools, warnings, validation,<br>
>> documentation, or voluntary hierarchical naming, but it does not<br>
>> automatically justify expanding mandatory registry authority.<br>
>><br>
>> There is also an important ethical question here. Policy power should not<br>
>> be enlarged merely because the proposed requirement appears useful, tidy,<br>
>> or widely adopted elsewhere. The burden lies with those seeking compulsion<br>
>> to show actual harm, necessity, proportionality, and the failure of less<br>
>> restrictive alternatives. Operators should not be forced to surrender<br>
>> discretion simply because an institution prefers uniformity.<br>
>><br>
>> The fact that four other RIRs adopted a similar convention is not proof<br>
>> that AFRINIC must do the same. Institutional repetition is not technical<br>
>> necessity, and participation in the PDWG should not become a ritual for<br>
>> ratifying choices already made elsewhere.<br>
>><br>
>> The registry should preserve number-resource uniqueness, registry accuracy,<br>
>> and operational continuity. It should not stretch those concepts until<br>
>> every preferred operational convention becomes mandatory policy.<br>
>><br>
>> For these reasons, I support Asamkele?s objection and remain opposed to the<br>
>> proposal.<br>
>><br>
>> Regards,<br>
>> Nonhlanhla<br>
>> On Sat, 18 Jul 2026, 9:08 pm Asamkele Menzeleli <<br>
>> <a href="mailto:asamkele.menzeleli18@maharishinstitute.org" target="_blank" rel="noreferrer">asamkele.menzeleli18@maharishinstitute.org</a>> wrote:<br>
>><br>
>>> Dear Hendrik,<br>
>>><br>
>>> I disagree with your characterization.<br>
>>><br>
>>> 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<br>
>> routing-policy<br>
>>> object. Confusing the naming convention of that object with the<br>
>> uniqueness<br>
>>> of the underlying number resource expands the meaning of ?uniqueness? far<br>
>>> beyond its proper technical scope.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> That distinction is precisely the concern I raised. Institutional<br>
>>> authority often expands by redefining a useful administrative preference<br>
>> as<br>
>>> a 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.<br>
>>><br>
>>> 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<br>
>> same<br>
>>> outcome.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> 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.<br>
>>><br>
>>> My objection therefore remains. The proposal has not shown that<br>
>> compulsory<br>
>>> hierarchical naming is necessary to protect number-resource uniqueness,<br>
>> nor<br>
>>> that the registry should extend its mandatory policy authority into this<br>
>>> area.<br>
>>><br>
>>> Regards,<br>
>>> Asamkele Menzeleli<br>
>>> _______________________________________________<br>
>>> RPD mailing list<br>
>>> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
>>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>>><br>
>> -------------- next part --------------<br>
>> An HTML attachment was scrubbed...<br>
>> URL: <<br>
>> <a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260718/7d3628bc/attachment.html</a><br>
>>><br>
>><br>
>> ------------------------------<br>
>><br>
>> Subject: Digest Footer<br>
>><br>
>> _______________________________________________<br>
>> RPD mailing list<br>
>> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
>> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
>><br>
>><br>
>> ------------------------------<br>
>><br>
>> End of RPD Digest, Vol 222, Issue 45<br>
>> ************************************<br>
>><br>
<br>
> _______________________________________________<br>
> RPD mailing list<br>
> <a href="mailto:RPD@afrinic.net" target="_blank" rel="noreferrer">RPD@afrinic.net</a><br>
> <a href="https://lists.afrinic.net/mailman/listinfo/rpd" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/mailman/listinfo/rpd</a><br>
<br>
</blockquote></div>