[rpd] RPD Digest, Vol 222, Issue 77

[Hendrik Visage]

Good day Zimkhitha,


On 19 Jul 2026, at 22:28, Zimkhitha Mguqulwa via RPD wrote:
>

> These are just genuine questions rather than objections. I think any 
> sort of discussions around these points would help me and potentially 
> others better understand whether the proposal is the most appropriate 
> solution.

Yes, genuine questions are welcomed!


> My first question links to the existing AS-SETs. To my understanding 
> (correct me if im wrong), the proposal only applies to newly created 
> objects, which i would assume leaves existing names unchanged. If that 
> is correct, how would the proposal deal with or rather address current 
> cases of name squatting or any existing naming conflicts. Would it not 
> be beneficial to resolve existing issues first rather than preventing 
> new occurrences?

Sections 7.8.4–7.8.6 are leaving the existing AS-SETs alone as there 
aren’t a simple method to know which ASN owns which existing AS-SET.
“Fixing exisitng issues” is not a AfriNIC only issue, and one 
registry can’t force another to make changes and the victims can’t 
change anything done by the squaters. What AfriNIC (and other with the 
same policies) will do by implementing this policy, is to prevent future 
collisions from happening inside their own whois databases - ie. be Good 
Netizens :)

> Secondly, I was also wondering whether any tests or assessments have 
> been done on operational impact for network operators. Has any 
> implementation experience or impact assessments been shared from other 
> regions that have adopted a similar approach to study how the progress 
> or changes?

The Proposal actually do mention all the other RIRs’ already active 
implementation status, and the tools (like bgp4) already handle it 
correctly with not operational impacts reported and the rest are also 
documented in the proposal

your question does overlap with the objectors, and for the record I’ll 
note that the objectors have two concrete questions they haven’t 
answered themselves:
(a) What should filter-generators (like bgp4) do when some (nefarious?) 
reason an empty AS-GOOGLE appear in AfriNIC’s database vs RADB’s 
populated AS-GOOGLE ?
(b) Under the proposed 'less restrictive alternatives', what remedy does 
a victim of AS-SET name squatting have to get the squatted object 
removed from a database they don't control?

Both questions await answers.

For documented harm, the record already holds it: the MANRS AS-AMAZON 
incident (2022), and the empty AS-GOOGLE in the RIPE DB that Frank 
showed side-by-side with RADB's populated one.
And for the record: the distinction between authenticating creation and 
validating membership has been agreed by the opposers themselves, and is 
consistent with the proposal's stated scope — the proposal claims 
nothing about membership content.

A practical example using my own ASN: today anyone — you, me, or a bad 
actor — can create AS-AMAZON or AS-GOOGLE in the open namespace, 
innocently or maliciously. Under this policy I could only create 
AS329532:AS-SOMETHING, because creation requires the maintainer 
credentials of AS329532. It is then always known which ASN holder 
created a set, and nobody can occupy a name under someone else's 
ASN.dentials of AS329532 — so it's always known which ASN holder 
created a set, and nobody can occupy a name under someone else's ASN.



---
Hendrik Visage
Director/Owner
HeViS.Co Systems t/a Envisage Cloud Solutions
hvisage at hevis.co.za
GSM/SMS/Signal: +27-84-612-5345
InstantMessenger: https://t.me/hvisage
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260719/937c3be8/attachment.html>