[rpd] AS-SETs ... Actual Stupidity and Artificial Intelligence

[Paul Hjul]

Please consider this mail in the context of the general "discussion" rather
than limited to AS-SET (where AS should not stand for actual stupidity ;) )
although I do make a specific comment on AFPUB-2026-ASN-001-DRAFT02. I was
quite sure that I had already voiced my support for the policy proposal at
the PPM but decided to take a proper look at the PPM recording. On watching
the video it is quite clear to me that unfortunately most of the "debate"
in the last call has been entirely disconnected from the discussion that
occurred at the PPM.

There are probably quite a few people who should familiarize themselves
with this video:
https://www.youtube.com/watch?v=MoB1ZjXgN44
The pool is not limited to "new" "contributors", nor to those accused of
astroturfing or misusing AI tools. I prefer any discussion to be using
artificial intelligence rather than evidencing actual stupidity. I really
do not like seeing AI being used to support stupidity.

Astroturfing is an interesting term here. The idea comes from the gigantic
and abandoned Astrodome in the United States and became a very apt way of
describing the activity of a funded (usually "dark money") political or
ideologically motivated operative undertaking activities to make it appear
that something has grassroots support.  As a general activity it is a
favourite past-time of "alt-right" and American organizations generally. If
there has been financial (or financial like) incentives for a group of
people to present themselves as grassroots then the charge fits. However
astroturfing and hidden motives and accusations around same are a staple of
things so I am a lot more interested in honest opinions from honest voices
(who tend to agree on some things and robustly disagree on others).

Speaking of the Americans though: As was pointed out at the PPM (in Nairobi
where quite a lot of the contributors on all sides of this odd "discussion"
did not participate) and then ignored in the exchange for quite a few days
this policy proposal is a part of an effort that involves proposals in
various fora and several efforts at implementation. Unfortunately the
discussion after the PPM has presented this policy as if it has been
adopted as a policy in all RIRs and that AFRINIC is at present a hold out.
This is not what the authors conveyed. There is not an emergency-esque
reason to get this policy as a policy and a good faith discussion about
whether it should be an RDP policy can be had. The issue is squarely stated
in the proposal and it was meaningfully raised for discussion at the PPM.
The fact is that ARIN's process for this sort of policy to be implemented
was rejected as out of scope. The matter did not arise in LACNIC as
the implementation was a feature of the relevant database from inception.
This is a relevant and important indicator that the question of whether a
policy in the RPD is the correct mechanism. If anybody wants to argue that
ARIN got it wrong I'll happily sign onto that train but ARIN's
PPML evidences so much weird stupidity that I really don't think that the
punting of this debate as out of scope was the worst possible call,
especially if there is a different means to achieve the end. Further the
adoption in RIPE was through the equivalent of the DBWG rather than the
PDWG. AFRINIC's webpage (https://afrinic.net/committees.html) gives a
description of " The PDWG develops and discusses policies relating to the
management and distribution of IPv4, IPv6 and ASNs in Africa" and on this
language the case could be made that a similar out of scope contention can
be advanced. The DBWG on the other hand says "The DBWG facilitates
discussion on AFRINIC's WHOIS Database and related services" but trusty
MSOffice Copilot warns me of a distinction between RIPE and AFRINIC
Database Working Group practice with AFRINIC allowing for discussion which
retaining final decision making to staff. I haven't seen any discussion in
the PDWG and that does strike me as a little odd. Again it is wrong to
attribute this to the authors of the proposal but it does suggest that some
of the discussion vehemently demanding this policy stems from something
other than the merits of the proposal.

It is possible that the true root of concern originates from the name of
this mailing list "Resource Policy Development" and that on
https://afrinic.net/email.html the description given is "Discussions about
Internet Number Resource Allocation Policies in the African region".
Therefore the (demonstrably incorrect) assumption underpinning objection is
that this policy will invariably cause "management" and a risk of scope
creep for AFRINIC even though wrong is not without some sprinkling. The PPM
in Nairobi was genuinely a positive development for AFRINIC but I am
starting to fear that the "era of good feelings" (phrase chosen as an
easter egg for people familiar with US political history) might be coming
to an end. Participants on the group talking about all other RIRs
"enforcing" here are as guilty of breaking down the discussion as anybody
else.

So let us take the primary objection given on its own face:
"The proposal appears technically modest, but it reflects a broader pattern
that AFRINIC should be moving away from, not reinforcing. Every new policy
that expands registry-defined objects, procedures, or institutional scope
should first answer a simple question: *does this protect uniqueness, or
does it expand the registry's governance surface?
A registry exists to maintain accurate records and protect uniqueness. It
may record. It may coordinate. It may protect uniqueness. It may not
rule.Once policy begins creating additional administrative structures that
are not strictly required for interoperability, we should ask whether we
are solving an Internet problem or an institutional one.*" (
https://lists.afrinic.net/pipermail/rpd/2026/015011.html)

The question is does this policy "expand registry-defined objects", does
the policy "creat[e] additional administrative structures". If it doesn't
then there is a simple way to show that it is the RFC which has defined the
behaviour and the policy merely informs pre-existing administrative
structures. Both of those answers though do keep the question of whether
the RPD is the right place considering that neither RIPE nor ARIN has had
adoption of practice through the equivalent mechanism.

My view - notwithstanding the nomenclature and fact that this pertains more
to a database matter etc ... - is that there is a good reason for this
policy process to be followed: namely that the policy proposes the
inclusion of language into the CPM. For this reason, if no other, some
discussion in this mailing list is apt. Put differently the name RDP and
the description given by AFRINIC probably misses the mark a little bit
because this list and the PPM determines the text found in the CPM even if
such text in the CPM are not concerned with "resource allocation" or
"management". It is my view that anything that will amend the CPM should be
conducted through the RPD and a PPM. I really do think the adoption
mechanism around last call and moving away from 6 month policy adoption
hold ups needs to be looked at but that is a separate discussion.

For this reason the email from a co-chair (
https://lists.afrinic.net/pipermail/rpd/2026/015004.html) should put the
matter in context. That email stipulates that AFPUB-2026-ASN-001-DRAFT02
has been put to last call (this aligns with the meeting) and provides a
link to the text as well as provides an important piece of context "please
note the staff observation regarding implementation constraints: due to the
current prioritization of the MyAFRINIC v2 deployment, physical database
implementation of this policy will be scheduled once the MyAFRINIC v2
deployment is concluded."

Looking at the policy proposal I remain of the view that it should be
supported in the *form presented by the authors*. However, I am concerned
at the possibility that  "7.8.7 Exceptions for the creation of hierarchical
names may be granted where necessary. AFRINIC shall document the reason for
any exception." is being assumed to enjoy "rough consensus". I object to
this specific language primarily because it introduces a severe risk of
mandate confusion. The author's language of "Exceptions MUST be allowed on
a case-by-case basis. For example, a non-hierarchically named AS-SET was
deleted by mistake, so it should be possible to restore this AS-SET without
having to rename it." is satisfactory and avoids the problem of introducing
peculiar exercises of discretion. In this respect I disagree with Jordi who
at the PPM suggested adopting the changes proposed by staff. The other
areas of clarification do not change the meaning and so I am not concerned
about that. I do however request that the co-chairs put out an email of the
exact text that will be appearing in the CPM.

The policy itself contains no imposition of enforcement or execution and
the caveat given by the co-chairs makes it clear that this policy is to
bind AFRINIC. For that reason most objections are erroneous.

However my - or for that matter anybody else's - support (with some
meaningless proclamations of support for both the policy and
implementation) is a little moot if the policy has been erroneously taken
to be up for last call. Therefore I checked the PPM recording and indeed
the document was referred to "last call: although it isn't clear whether
the draft as given by the authors or whether the final call is on the basis
of an amended text.  A healthy debate - albeit a pedantic one - as to
whether the changes for clarification proposed by staff - should be taken
up on last call to a given proposal is probably overdue and I am more
concerned about what we've seen with both the the dashboard proposal and
the transfer policy (which I dealt with a few weeks ago). In my view - and
this is the proposition I have made concerning the IPv6 tie to soft-landing
and a host of similar instances - is that in quite a lot of instances where
a policy will have unintended but identifiable consequences which
consequences aren't understood just yet there is likely room in adopting
the policy understanding that as evidence surfaces the policy can be
revised. I must however note that some of the objections to the IPv6
promoting policies can be advanced against this policy.

On a fair reading of the CPM once amended I don't think the policy is
superfluous nor that it imposes obligations on resource holders but rather
on AFRINIC. I do not see anything in the policy proposal as written which
would give rise to an "enforcement" or attempt at sanction. But we do need
clarity as to whether the text has been changed from that which is
appearing in the draft.

In my view the approach of a specification underlies a policy which is
achieved through an implementation is usually an apt model. Here the
specification is RFC 2622, the policy at AFRINIC would be the text of CPM
7.8 and the implementation would be on the database systems.
I can understand any objection that would be raised against a policy which
imposes an implementation on resource holders. However, *as written*, the
policy does not do that. The trouble is that at least one policy, as
written, once adopted does create a problem (discussed here:
https://lists.afrinic.net/pipermail/rpd/2026/014784.html) and is the
subject of litigation which can't actually be defended. On top of that the
compliance dashboard policy proposal has been neutered and it appears this
is to frame that policy to impose on resource holders. Put simply if the
environment is such that resource holders perceive a policy proposal as
impacting on their interests then the incentive to astroturf is created.
The way to solve the problem is to ensure that the policy developments are
done properly throughout.

Therefore my earnest appeal is that actual stupidity be avoided and that
this aspect of database record keeping be prioritized into the next set of
implementation changes of the relevant systems that AFRINIC uses. That the
co-chairs give clarity as to whether there are any textual amendments as
well as clarity on the implementation plan. I submit that the
implementation plan (coming from AFRINIC) should set out that the expected
date of deployment is X but may be postponed to align with the rollout of
MyAfrinic v2 and that implementation will occur on the service side and not
affect resource holders.

As for the discussion on AI tools. I think the sort of stance that should
be taken is: Participants in the PDWG are permitted to use AI tools in
order to improve the clarity of expression and to assist with language in
their contribution. Participants using AI tools are encouraged to align
such tools with brevity and technical clarity. The use of automations to
generate batch contributions and a nuisance on the list is not permitted.

Of course I would be in opposition of any policy or approach that precludes
the use of sarcasm or tangents that are not a product of AI.

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20260721/119d91ac/attachment-0001.html>