<div dir="auto"><div dir="auto">Dear Mr Hendrik,<br><br>It is hard to reconcile your position with the digital future that AFRINIC itself is promoting.<br><br>This community encourages the use of technology such as IPv6 transition, automation and modern network tools. Yet when participants use online resources to organize their contributions, that same technological progress is suddenly seen as a cause for suspicion or exclusion.<br><br>The question is not whether assistance was used. It is whether or not the message is from a real person and whether or not the argument is sound.<br><br>Digital inclusion can’t be about embracing technology only when the incumbents like the user.<br><br>Concentrate on the policy objections, rather than attempting to discredit the people making them.<br><br>Kind regards,<br></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, 8:10 pm <<a href="mailto:rpd-request@afrinic.net">rpd-request@afrinic.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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) and Amendment of<br>
Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02)<br>
(Hendrik Visage)<br>
2. Re: RPD Digest, Vol 222, Issue 45 (Gugu Dhlamini)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Sun, 19 Jul 2026 20:04:03 +0200<br>
From: Hendrik Visage <<a href="mailto:hvisage@hevis.co.za" target="_blank" rel="noreferrer">hvisage@hevis.co.za</a>><br>
To: Thulisile Mazomba <<a href="mailto:219280444@mycput.ac.za" target="_blank" rel="noreferrer">219280444@mycput.ac.za</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) and Amendment of<br>
Utilisation in Soft Landing (AFPUB-2026-IPv4-002-DRAFT02)<br>
Message-ID: <<a href="mailto:0B9F65CE-7417-4996-84C6-7E395FB27544@hevis.co.za" target="_blank" rel="noreferrer">0B9F65CE-7417-4996-84C6-7E395FB27544@hevis.co.za</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Dear Thulisile,<br>
<br>
Why did you also use an AI to respond?<br>
<br>
Claude: `Yes ? and it's the same drafting pipeline again, now writing <br>
a defense of itself. That's the most interesting thing about this one: <br>
the thread has become recursive, and the message quotes my own analysis <br>
back while exhibiting the exact markers that analysis described.a<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 19 Jul 2026, at 19:39, Thulisile Mazomba wrote:<br>
<br>
> Dear colleagues,<br>
><br>
> This discussion has moved away from the proposal and toward <br>
> questioning who is allowed to object.<br>
><br>
> Whether someone operates an ASN, uses drafting assistance, is new to <br>
> the list, or is unfamiliar to long-standing participants does not <br>
> determine whether their argument is valid. The PDP should examine the <br>
> substance of an objection, not attempt to infer authorship from <br>
> writing style or rank participants according to reputation.<br>
><br>
> Submitting text to another language model does not establish who wrote <br>
> it, who contributed to it, or whether the person posting it agrees <br>
> with it. A probability produced by Claude is not evidence of <br>
> astroturfing. It is an automated opinion about prose.<br>
><br>
> Hendrik?s own quoted analysis concedes the important point: the <br>
> distinction between authenticating the creator of an AS-SET and <br>
> validating its contents is a real objection that still requires an <br>
> answer. That issue does not disappear because the wording appears <br>
> polished.<br>
><br>
> The request to identify which ASNs objectors ?represent? also <br>
> misunderstands participation. I am not claiming to represent every <br>
> African operator, nor should any individual participant make that <br>
> claim without authority. I am participating in my own capacity. An ASN <br>
> is not a voting credential, and operating one does not give its holder <br>
> a larger mandate over the policy process.<br>
><br>
> Frank?s road-rule analogy is also misplaced. Governments impose <br>
> traffic laws through public authority and accept legal accountability <br>
> for doing so. AFRINIC is a private registry operating a technical <br>
> database. The existence of a working group does not turn that registry <br>
> into a legislature or every preferred operational practice into the <br>
> equivalent of public law.<br>
><br>
> The question before us remains simple: does this proposal solve the <br>
> specific harm claimed, and is mandatory registry enforcement the <br>
> minimum necessary mechanism?<br>
><br>
> Hierarchical naming may reduce future name collisions. That is a <br>
> useful property. It does not validate the accuracy of AS-SET <br>
> membership, prevent incorrect customer-cone data, or make generated <br>
> filters trustworthy by itself. Those limitations should be assessed <br>
> honestly rather than buried beneath accusations about who wrote which <br>
> paragraph.<br>
><br>
> If the co-chairs believe several objections raise the same substantive <br>
> issue, they may group them as one issue. That is reasonable. But they <br>
> should then determine whether the issue has been answered on its <br>
> merits. They should not discount it because the participants are <br>
> unfamiliar, share a view, use similar language, or may have used <br>
> writing tools.<br>
><br>
> Participation provides evidence, criticism, and warning. Familiarity <br>
> does not create mandate. Reputation does not replace proof. A mailing <br>
> list should not become a private club in which established names <br>
> decide which speakers count.<br>
><br>
> I remain opposed to the proposal and ask that the discussion return to <br>
> the proposal?s technical scope, demonstrated benefit, limitations, <br>
> and proportionality.<br>
><br>
> Regards,<br>
> Thulisile<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260719/421ab07f/attachment-0001.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260719/421ab07f/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Sun, 19 Jul 2026 20:09:25 +0200<br>
From: Gugu Dhlamini <<a href="mailto:gugudhlamini343@gmail.com" target="_blank" rel="noreferrer">gugudhlamini343@gmail.com</a>><br>
To: Frank Habicht <<a href="mailto:geier@geier.ne.tz" target="_blank" rel="noreferrer">geier@geier.ne.tz</a>>, <a href="mailto:rpd-owner@afrinic.net" target="_blank" rel="noreferrer">rpd-owner@afrinic.net</a><br>
Cc: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: Re: [rpd] RPD Digest, Vol 222, Issue 45<br>
Message-ID:<br>
<<a href="mailto:CADMrvbNHq%2Bu4HTi1r9qNoX4A9LH69czSnPoAAeVPSYq8oai01A@mail.gmail.com" target="_blank" rel="noreferrer">CADMrvbNHq+u4HTi1r9qNoX4A9LH69czSnPoAAeVPSYq8oai01A@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Dear Frank,<br>
<br>
A problem statement establishes that a concern exists. It does not<br>
establish that this proposal is necessary, proportionate, or the only valid<br>
remedy.<br>
<br>
Questioning and asking that contributions be disregarded because their<br>
wording appears similar is not consensus assessment. It is #Gatekeeping.<br>
Participation may provide evidence and objection; familiarity and style do<br>
not create or remove mandate.<br>
<br>
Please answer the unresolved policy concern rather than analyse the people<br>
raising it.<br>
<br>
I remain opposed.<br>
<br>
Regards,<br>
Gugu<br>
<br>
On Sun, 19 Jul 2026, 3:00 pm Frank Habicht <<a href="mailto:geier@geier.ne.tz" target="_blank" rel="noreferrer">geier@geier.ne.tz</a>> wrote:<br>
<br>
> Hi,<br>
><br>
> inline...<br>
><br>
> On 7/18/2026 10:49 PM, Nia Petronella wrote:<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<br>
> > they have raised. A collision between AS-SET labels is not a failure of<br>
> > ASN or prefix uniqueness,<br>
><br>
> It is a failure of AS-SET uniqueness.<br>
> Which are not among the famous 3 INR that AfriNIC primarily deals with.<br>
> But they are important objects in the IRR. Which AfriNIC operates. And<br>
> thus AfriNIC should set the policies under which it operates the IRR.<br>
><br>
> > and repeating that characterization does not<br>
> > make it technically correct.<br>
><br>
> Maybe my above statement is not a repetition, and could be technically<br>
> correct?<br>
><br>
> > The proposal still has not demonstrated measurable operational harm,<br>
><br>
> Would it be better if someone would have added this to the proposal:<br>
> "" MANRS documented the incident with AS-AMAZON back in 2022,<br>
><br>
> <a href="https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/" rel="noreferrer noreferrer" target="_blank">https://manrs.org/2022/12/why-network-operators-should-use-hierarchical-as-sets/</a>.<br>
><br>
> At the time of writing Google's official source for their AS-SET is RADB<br>
> as documented in their PeeringDB entry<br>
> <a href="https://www.peeringdb.com/net/433" rel="noreferrer noreferrer" target="_blank">https://www.peeringdb.com/net/433</a>, but AS-GOOGLE currently exists as an<br>
> empty AS-SET in the RIPE DB<br>
><br>
> <a href="https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set" rel="noreferrer noreferrer" target="_blank">https://apps.db.ripe.net/db-web-ui/lookup?source=ripe&key=AS-GOOGLE&type=as-set</a>.<br>
><br>
> ""<br>
><br>
> Would you then agree that the proposal demonstrated harm?<br>
><br>
> Just because you didn't see it doesn't mean there was no harm.<br>
><br>
><br>
> > why<br>
> > voluntary hierarchical naming is insufficient,<br>
><br>
> the author posted on this mailing list the number of collisions that exist.<br>
><br>
> > or why mandatory registry<br>
> > intervention is the least restrictive solution.<br>
><br>
> This is where you can propose a less restrictive solution.<br>
><br>
> > Adoption by other RIRs<br>
> > is relevant, but institutional uniformity is not proof of technical<br>
> > necessity.<br>
><br>
> Harm that was documented is the 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.<br>
><br>
> Thanks. Was the AI asked to produce a certain quantity of text, so that<br>
> this blah had to be included?<br>
><br>
> > The<br>
> > registry should support accurate routing information without converting<br>
> > every preferred convention into compulsory policy.<br>
><br>
> Now, I have a question.<br>
><br>
> If "the registry" (AfriNIC) gets this information:<br>
><br>
> as-set: AS-GOOGLE<br>
> tech-c: AS156-AFRINIC<br>
> admin-c: AS156-AFRINIC<br>
> mnt-by: google_kenya<br>
> source: AFRINIC # Filtered<br>
> descr: AS-GOOGLE<br>
><br>
><br>
> and another registry (RADB) has this information:<br>
><br>
> as-set: AS-GOOGLE<br>
> descr: Google<br>
> members: AS11344<br>
> members: AS13949<br>
> members: AS15169<br>
> members: AS15276<br>
> members: AS19425<br>
> members: AS22577<br>
> members: AS26910<br>
> members: AS36040<br>
> members: AS36384<br>
> members: AS36492<br>
> members: AS36561<br>
> members: AS394725<br>
> members: AS40873<br>
> members: AS41264<br>
> members: AS43515<br>
> members: AS55023<br>
> members: AS6432<br>
> members: AS19527<br>
> members: AS26684<br>
> members: AS395973<br>
> members: AS36039<br>
> members: AS24424<br>
> members: AS396982<br>
> members: AS139070<br>
> members: AS139190<br>
> members: AS394699<br>
> members: AS-GOOGLE-IT<br>
> members: AS-MEEBO<br>
> members: AS-METAWEB-2<br>
> members: AS32381<br>
> members: AS36383<br>
> members: AS36411<br>
> members: AS36520<br>
> members: AS394089<br>
> mnt-by: MAINT-AS15169<br>
> changed: <a href="mailto:arturolev@google.com" target="_blank" rel="noreferrer">arturolev@google.com</a> 20231030 #16:36:58Z<br>
> source: RADB<br>
> last-modified: 2023-11-13T16:19:21Z<br>
><br>
> then what should the person or the software generating a prefix-filter do?<br>
><br>
> Awaiting this answer.<br>
><br>
> It's important. Because this is what this discussion is about. Any<br>
> indication that the opponents have understood this will be welcome.<br>
><br>
> Frank Habicht<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a7141280/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260719/a7141280/attachment.html</a>><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 69<br>
************************************<br>
</blockquote></div>