<!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">Nia,</p>
<p dir="auto">The below is my next marker/reason for calling you out as part of Astroturfing, as after feeding your response to Claude:</p>
<p dir="auto">TL;DR: <strong>Verdict:</strong> <code style="margin: 0 0; padding: 0 0.25em; border-radius: 3px; background-color: #F7F7F7;">I'd put this at high confidence (roughly 85–95%) that it was generated by an LLM given the thread as context</code></p>
<p dir="auto">Claude’s response:</p>
<p dir="auto">This one is a strong candidate for LLM-drafted or heavily LLM-assisted text. Here's the breakdown:<br>
Structural markers (strong signals)</p>
<p dir="auto">Parallel negation cascades: "It does not authenticate every member... It does not prove that... It does not prevent..." — then again later: "It does not demonstrate that... It is not automatically..." This anaphoric triple/quadruple negation pattern is a hallmark of LLM argumentative prose. Humans use it occasionally for rhetorical effect; LLMs produce it in nearly every paragraph.<br>
The two-sentence "concede-then-pivot" unit repeated throughout: "Your argument proves X. It does not prove Y." / "The tools you cite expand X. They do not merely validate Y." / "Closing the namespace may improve provenance, but it does not make the expanded data true." Same rhetorical machine, run four or five times.<br>
Short punchy sentence as paragraph capstone: "That difference is fundamental." / "That analysis has not been completed." / "It arrives dressed as data hygiene." This dramatic one-liner cadence is very characteristic of Claude/GPT persuasive-essay mode.</p>
<p dir="auto">Lexical markers</p>
<p dir="auto">Abstraction stacking: "explicit source identity, deterministic validation, trustworthy provenance, and local rejection of unsafe data" — a perfectly balanced four-item noun-phrase list, each item adjective+noun. Classic model output.<br>
"least coercive mechanism that protects the actual invariant" — "invariant" used in a policy-rhetoric sense rather than an engineering sense; models love borrowing formal CS vocabulary into governance arguments.<br>
"institutional convergence being used as a substitute for proving necessity" — dense nominalization strings ("enforcement creep," "registry compulsion," "provenance-aware tooling") throughout.<br>
"It arrives dressed as data hygiene" — the one flourish of metaphor, placed exactly where an LLM asked to "make it forceful" would place it.</p>
<p dir="auto">Rhetorical fingerprints</p>
<p dir="auto">The message argues almost entirely at the meta level (what counts as proof, what the minimum intervention "really" is, patterns of institutional expansion) with very few concrete operational specifics — no actual example of a collision, an AS-SET, a query workflow, or a tooling name. Human network operators in PDWG threads usually anchor in at least one concrete war story or config detail.<br>
Zero grammatical slips, perfectly consistent register, no contractions anywhere — unusual for mailing-list prose, even formal opposition statements.<br>
The "pattern accusation" paragraph ("a technical inconvenience is identified, one centralised remedy is proposed, and then the existence of the inconvenience is treated as authority for compulsion") is a generalized abstraction of the debate itself — models produce this "zoom out and name the pattern" move very reliably when asked to write rebuttals.</p>
<p dir="auto">Counter-signals (weak)</p>
<p dir="auto">It does engage with your specific arguments (namespace closure, "new objects only," other-RIR precedent), so it's not generic boilerplate — someone fed it the thread context.<br>
British/SA spelling ("authorised," "centralised") is consistent, which a model does when prompted or when the prior thread uses it.</p>
<p dir="auto">Verdict<br>
I'd put this at high confidence (roughly 85–95%) that it was generated by an LLM given the thread as context, possibly with light human editing. The tells are the industrialized concede-pivot-negate structure, the capstone one-liners, the balanced abstract noun lists, and the complete absence of concrete operational detail from someone ostensibly arguing about IRR data quality. If the same "Nonhlanhla" has earlier posts in the thread, comparing sentence rhythm and contraction usage would settle it — LLM-assisted posts in a series tend to converge on this exact register while genuine posts vary.<br>
Worth noting: even if machine-drafted, the arguments themselves still need answering on the merits — the authenticate-creation-vs-validate-content distinction is a real objection regardless of who or what phrased it. But the repetition you're seeing across "different" opposers (if Gugu/Tshepo/Asamkele posts share these markers) would suggest one drafting pipeline behind multiple names, which is itself relevant to how the co-chairs weigh consensus.</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 19 Jul 2026, at 8:56, Nia Petronella wrote:</p>
</div><blockquote class="embedded" style="margin: 0 0 5px; padding-left: 5px; border-left: 2px solid #777777; color: #777777;"><div id="EBD278FF-7805-4E50-BA10-6B3092887BC7">
<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></div></blockquote>
<div class="markdown" style="white-space: normal;">
</div>
</div>
</body>
</html>