<div dir="ltr"><div dir="ltr"><div>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.</div><div><br></div><div>There are probably quite a few people who should familiarize themselves with this video:</div><div><a href="https://www.youtube.com/watch?v=MoB1ZjXgN44" target="_blank">https://www.youtube.com/watch?v=MoB1ZjXgN44</a></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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. <span style="background-color:transparent">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 (</span><a href="https://afrinic.net/committees.html">https://afrinic.net/committees.html</a>) gives a description of "<span style="background-color:transparent"> </span><span style="background-color:transparent">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 "</span><span style="background-color:transparent">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.</span></div><div><br></div><div>It is possible that the true root of concern originates from the name of this mailing list "Resource Policy Development" and that on <a href="https://afrinic.net/email.html">https://afrinic.net/email.html</a> 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.</div><div><br></div><div>So let us take the primary objection given on its own face:</div><div>"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? <br>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.*" (<a href="https://lists.afrinic.net/pipermail/rpd/2026/015011.html">https://lists.afrinic.net/pipermail/rpd/2026/015011.html</a>)</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>For this reason the email from a co-chair (<a href="https://lists.afrinic.net/pipermail/rpd/2026/015004.html">https://lists.afrinic.net/pipermail/rpd/2026/015004.html</a>) 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 "p<span style="background-color:transparent">lease 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." </span></div><div><br></div><div>Looking at the policy proposal I remain of the view that it should be supported in the <b>form presented by the authors</b>. 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. <span style="background-color:transparent">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.</span></div><div><span style="background-color:transparent"><br></span></div><div><span style="background-color:transparent">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.  </span></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div>I can understand any objection that would be raised against a policy which imposes an implementation on resource holders. However, <b>as written</b>, the policy does not do that. The trouble is that at least one policy, as written, once adopted does create a problem (discussed here: <a href="https://lists.afrinic.net/pipermail/rpd/2026/014784.html">https://lists.afrinic.net/pipermail/rpd/2026/014784.html</a>) 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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>Paul</div></div>
</div>