<div dir="auto">Dear Paul,<div dir="auto"><br></div><div dir="auto">Your own framing points to the central issue.</div><div dir="auto"><br></div><div dir="auto">RFC 2622 provides the specification, and AFRINIC’s database provides the implementation. The disputed extra layer is policy. If this is a service-side change that creates no obligation, sanction, or operational burden for resource holders, then a transparent implementation plan should be sufficient.</div><div dir="auto"><br></div><div dir="auto">A technical specification does not automatically require an institutional mandate. Policy creates permanence, interpretation risk, and precedent beyond the immediate database change. “It affects AFRINIC, not resource holders” is therefore not a complete safeguard, because AFRINIC remains the institution interpreting and enforcing the resulting rule.</div><div dir="auto"><br></div><div dir="auto">I support your request for the exact text and implementation plan. They should also state plainly that the change:</div><div dir="auto"><br></div><div dir="auto">is implemented only on the service side;</div><div dir="auto"><br></div><div dir="auto">creates no compliance duty or sanction for resource holders;</div><div dir="auto"><br></div><div dir="auto">cannot be extended to existing objects without a new review;</div><div dir="auto"><br></div><div dir="auto">and will be measured and reconsidered if the expected operational benefit does not appear.</div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">On AI tools, the standard should be tool-neutral. Moderate actual flooding or automated nuisance, but judge ordinary contributions by their substance. A person who reviews and submits a message remains responsible for it.</div><div dir="auto"><br></div><div dir="auto">The registry should implement what the system technically requires. It should not turn implementation convenience into permanent policy authority.</div><div dir="auto"><br></div><div dir="auto">Regards,</div><div dir="auto">Nonhlanhla </div><div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 21 Jul 2026, 3:54 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. AS-SETs ... Actual Stupidity and Artificial Intelligence<br>
(Paul Hjul)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 21 Jul 2026 15:53:17 +0200<br>
From: Paul Hjul <<a href="mailto:hjul.paul@gmail.com" target="_blank" rel="noreferrer">hjul.paul@gmail.com</a>><br>
To: <a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a><br>
Subject: [rpd] AS-SETs ... Actual Stupidity and Artificial<br>
Intelligence<br>
Message-ID:<br>
<CAF4kYptTT9eNPaZ5qeNLdjvjMeG29k1KPA6pCGYGabfUB_J=<a href="mailto:pQ@mail.gmail.com" target="_blank" rel="noreferrer">pQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Please consider this mail in the context of the general "discussion" rather<br>
than limited to AS-SET (where AS should not stand for actual stupidity ;) )<br>
although I do make a specific comment on AFPUB-2026-ASN-001-DRAFT02. I was<br>
quite sure that I had already voiced my support for the policy proposal at<br>
the PPM but decided to take a proper look at the PPM recording. On watching<br>
the video it is quite clear to me that unfortunately most of the "debate"<br>
in the last call has been entirely disconnected from the discussion that<br>
occurred at the PPM.<br>
<br>
There are probably quite a few people who should familiarize themselves<br>
with this video:<br>
<a href="https://www.youtube.com/watch?v=MoB1ZjXgN44" rel="noreferrer noreferrer" target="_blank">https://www.youtube.com/watch?v=MoB1ZjXgN44</a><br>
The pool is not limited to "new" "contributors", nor to those accused of<br>
astroturfing or misusing AI tools. I prefer any discussion to be using<br>
artificial intelligence rather than evidencing actual stupidity. I really<br>
do not like seeing AI being used to support stupidity.<br>
<br>
Astroturfing is an interesting term here. The idea comes from the gigantic<br>
and abandoned Astrodome in the United States and became a very apt way of<br>
describing the activity of a funded (usually "dark money") political or<br>
ideologically motivated operative undertaking activities to make it appear<br>
that something has grassroots support. As a general activity it is a<br>
favourite past-time of "alt-right" and American organizations generally. If<br>
there has been financial (or financial like) incentives for a group of<br>
people to present themselves as grassroots then the charge fits. However<br>
astroturfing and hidden motives and accusations around same are a staple of<br>
things so I am a lot more interested in honest opinions from honest voices<br>
(who tend to agree on some things and robustly disagree on others).<br>
<br>
Speaking of the Americans though: As was pointed out at the PPM (in Nairobi<br>
where quite a lot of the contributors on all sides of this odd "discussion"<br>
did not participate) and then ignored in the exchange for quite a few days<br>
this policy proposal is a part of an effort that involves proposals in<br>
various fora and several efforts at implementation. Unfortunately the<br>
discussion after the PPM has presented this policy as if it has been<br>
adopted as a policy in all RIRs and that AFRINIC is at present a hold out.<br>
This is not what the authors conveyed. There is not an emergency-esque<br>
reason to get this policy as a policy and a good faith discussion about<br>
whether it should be an RDP policy can be had. The issue is squarely stated<br>
in the proposal and it was meaningfully raised for discussion at the PPM.<br>
The fact is that ARIN's process for this sort of policy to be implemented<br>
was rejected as out of scope. The matter did not arise in LACNIC as<br>
the implementation was a feature of the relevant database from inception.<br>
This is a relevant and important indicator that the question of whether a<br>
policy in the RPD is the correct mechanism. If anybody wants to argue that<br>
ARIN got it wrong I'll happily sign onto that train but ARIN's<br>
PPML evidences so much weird stupidity that I really don't think that the<br>
punting of this debate as out of scope was the worst possible call,<br>
especially if there is a different means to achieve the end. Further the<br>
adoption in RIPE was through the equivalent of the DBWG rather than the<br>
PDWG. AFRINIC's webpage (<a href="https://afrinic.net/committees.html" rel="noreferrer noreferrer" target="_blank">https://afrinic.net/committees.html</a>) gives a<br>
description of " The PDWG develops and discusses policies relating to the<br>
management and distribution of IPv4, IPv6 and ASNs in Africa" and on this<br>
language the case could be made that a similar out of scope contention can<br>
be advanced. The DBWG on the other hand says "The DBWG facilitates<br>
discussion on AFRINIC's WHOIS Database and related services" but trusty<br>
MSOffice Copilot warns me of a distinction between RIPE and AFRINIC<br>
Database Working Group practice with AFRINIC allowing for discussion which<br>
retaining final decision making to staff. I haven't seen any discussion in<br>
the PDWG and that does strike me as a little odd. Again it is wrong to<br>
attribute this to the authors of the proposal but it does suggest that some<br>
of the discussion vehemently demanding this policy stems from something<br>
other than the merits of the proposal.<br>
<br>
It is possible that the true root of concern originates from the name of<br>
this mailing list "Resource Policy Development" and that on<br>
<a href="https://afrinic.net/email.html" rel="noreferrer noreferrer" target="_blank">https://afrinic.net/email.html</a> the description given is "Discussions about<br>
Internet Number Resource Allocation Policies in the African region".<br>
Therefore the (demonstrably incorrect) assumption underpinning objection is<br>
that this policy will invariably cause "management" and a risk of scope<br>
creep for AFRINIC even though wrong is not without some sprinkling. The PPM<br>
in Nairobi was genuinely a positive development for AFRINIC but I am<br>
starting to fear that the "era of good feelings" (phrase chosen as an<br>
easter egg for people familiar with US political history) might be coming<br>
to an end. Participants on the group talking about all other RIRs<br>
"enforcing" here are as guilty of breaking down the discussion as anybody<br>
else.<br>
<br>
So let us take the primary objection given on its own face:<br>
"The proposal appears technically modest, but it reflects a broader pattern<br>
that AFRINIC should be moving away from, not reinforcing. Every new policy<br>
that expands registry-defined objects, procedures, or institutional scope<br>
should first answer a simple question: *does this protect uniqueness, or<br>
does it expand the registry's governance surface?<br>
A registry exists to maintain accurate records and protect uniqueness. It<br>
may record. It may coordinate. It may protect uniqueness. It may not<br>
rule.Once policy begins creating additional administrative structures that<br>
are not strictly required for interoperability, we should ask whether we<br>
are solving an Internet problem or an institutional one.*" (<br>
<a href="https://lists.afrinic.net/pipermail/rpd/2026/015011.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2026/015011.html</a>)<br>
<br>
The question is does this policy "expand registry-defined objects", does<br>
the policy "creat[e] additional administrative structures". If it doesn't<br>
then there is a simple way to show that it is the RFC which has defined the<br>
behaviour and the policy merely informs pre-existing administrative<br>
structures. Both of those answers though do keep the question of whether<br>
the RPD is the right place considering that neither RIPE nor ARIN has had<br>
adoption of practice through the equivalent mechanism.<br>
<br>
My view - notwithstanding the nomenclature and fact that this pertains more<br>
to a database matter etc ... - is that there is a good reason for this<br>
policy process to be followed: namely that the policy proposes the<br>
inclusion of language into the CPM. For this reason, if no other, some<br>
discussion in this mailing list is apt. Put differently the name RDP and<br>
the description given by AFRINIC probably misses the mark a little bit<br>
because this list and the PPM determines the text found in the CPM even if<br>
such text in the CPM are not concerned with "resource allocation" or<br>
"management". It is my view that anything that will amend the CPM should be<br>
conducted through the RPD and a PPM. I really do think the adoption<br>
mechanism around last call and moving away from 6 month policy adoption<br>
hold ups needs to be looked at but that is a separate discussion.<br>
<br>
For this reason the email from a co-chair (<br>
<a href="https://lists.afrinic.net/pipermail/rpd/2026/015004.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2026/015004.html</a>) should put the<br>
matter in context. That email stipulates that AFPUB-2026-ASN-001-DRAFT02<br>
has been put to last call (this aligns with the meeting) and provides a<br>
link to the text as well as provides an important piece of context "please<br>
note the staff observation regarding implementation constraints: due to the<br>
current prioritization of the MyAFRINIC v2 deployment, physical database<br>
implementation of this policy will be scheduled once the MyAFRINIC v2<br>
deployment is concluded."<br>
<br>
Looking at the policy proposal I remain of the view that it should be<br>
supported in the *form presented by the authors*. However, I am concerned<br>
at the possibility that "7.8.7 Exceptions for the creation of hierarchical<br>
names may be granted where necessary. AFRINIC shall document the reason for<br>
any exception." is being assumed to enjoy "rough consensus". I object to<br>
this specific language primarily because it introduces a severe risk of<br>
mandate confusion. The author's language of "Exceptions MUST be allowed on<br>
a case-by-case basis. For example, a non-hierarchically named AS-SET was<br>
deleted by mistake, so it should be possible to restore this AS-SET without<br>
having to rename it." is satisfactory and avoids the problem of introducing<br>
peculiar exercises of discretion. In this respect I disagree with Jordi who<br>
at the PPM suggested adopting the changes proposed by staff. The other<br>
areas of clarification do not change the meaning and so I am not concerned<br>
about that. I do however request that the co-chairs put out an email of the<br>
exact text that will be appearing in the CPM.<br>
<br>
The policy itself contains no imposition of enforcement or execution and<br>
the caveat given by the co-chairs makes it clear that this policy is to<br>
bind AFRINIC. For that reason most objections are erroneous.<br>
<br>
However my - or for that matter anybody else's - support (with some<br>
meaningless proclamations of support for both the policy and<br>
implementation) is a little moot if the policy has been erroneously taken<br>
to be up for last call. Therefore I checked the PPM recording and indeed<br>
the document was referred to "last call: although it isn't clear whether<br>
the draft as given by the authors or whether the final call is on the basis<br>
of an amended text. A healthy debate - albeit a pedantic one - as to<br>
whether the changes for clarification proposed by staff - should be taken<br>
up on last call to a given proposal is probably overdue and I am more<br>
concerned about what we've seen with both the the dashboard proposal and<br>
the transfer policy (which I dealt with a few weeks ago). In my view - and<br>
this is the proposition I have made concerning the IPv6 tie to soft-landing<br>
and a host of similar instances - is that in quite a lot of instances where<br>
a policy will have unintended but identifiable consequences which<br>
consequences aren't understood just yet there is likely room in adopting<br>
the policy understanding that as evidence surfaces the policy can be<br>
revised. I must however note that some of the objections to the IPv6<br>
promoting policies can be advanced against this policy.<br>
<br>
On a fair reading of the CPM once amended I don't think the policy is<br>
superfluous nor that it imposes obligations on resource holders but rather<br>
on AFRINIC. I do not see anything in the policy proposal as written which<br>
would give rise to an "enforcement" or attempt at sanction. But we do need<br>
clarity as to whether the text has been changed from that which is<br>
appearing in the draft.<br>
<br>
In my view the approach of a specification underlies a policy which is<br>
achieved through an implementation is usually an apt model. Here the<br>
specification is RFC 2622, the policy at AFRINIC would be the text of CPM<br>
7.8 and the implementation would be on the database systems.<br>
I can understand any objection that would be raised against a policy which<br>
imposes an implementation on resource holders. However, *as written*, the<br>
policy does not do that. The trouble is that at least one policy, as<br>
written, once adopted does create a problem (discussed here:<br>
<a href="https://lists.afrinic.net/pipermail/rpd/2026/014784.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/2026/014784.html</a>) and is the<br>
subject of litigation which can't actually be defended. On top of that the<br>
compliance dashboard policy proposal has been neutered and it appears this<br>
is to frame that policy to impose on resource holders. Put simply if the<br>
environment is such that resource holders perceive a policy proposal as<br>
impacting on their interests then the incentive to astroturf is created.<br>
The way to solve the problem is to ensure that the policy developments are<br>
done properly throughout.<br>
<br>
Therefore my earnest appeal is that actual stupidity be avoided and that<br>
this aspect of database record keeping be prioritized into the next set of<br>
implementation changes of the relevant systems that AFRINIC uses. That the<br>
co-chairs give clarity as to whether there are any textual amendments as<br>
well as clarity on the implementation plan. I submit that the<br>
implementation plan (coming from AFRINIC) should set out that the expected<br>
date of deployment is X but may be postponed to align with the rollout of<br>
MyAfrinic v2 and that implementation will occur on the service side and not<br>
affect resource holders.<br>
<br>
As for the discussion on AI tools. I think the sort of stance that should<br>
be taken is: Participants in the PDWG are permitted to use AI tools in<br>
order to improve the clarity of expression and to assist with language in<br>
their contribution. Participants using AI tools are encouraged to align<br>
such tools with brevity and technical clarity. The use of automations to<br>
generate batch contributions and a nuisance on the list is not permitted.<br>
<br>
Of course I would be in opposition of any policy or approach that precludes<br>
the use of sarcasm or tangents that are not a product of AI.<br>
<br>
Paul<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260721/119d91ac/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260721/119d91ac/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 138<br>
*************************************<br>
</blockquote></div>