<div dir="auto">Dear Frank,<div dir="auto"><br></div><div dir="auto">A problem statement establishes that a concern exists. It does not establish that this proposal is necessary, proportionate, or the only valid remedy.</div><div dir="auto"><br></div><div dir="auto">Questioning and asking that contributions be disregarded because their wording appears similar is not consensus assessment. It is #Gatekeeping. Participation may provide evidence and objection; familiarity and style do not create or remove mandate.</div><div dir="auto"><br></div><div dir="auto">Please answer the unresolved policy concern rather than analyse the people raising it.</div><div dir="auto"><br></div><div dir="auto">I remain opposed.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Gugu</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, 19 Jul 2026, 3:00 pm Frank Habicht <<a href="mailto:geier@geier.ne.tz">geier@geier.ne.tz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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>
<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>
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>
<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>
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>
</blockquote></div>