<div dir="auto"><p style="font-size:12.8px;background-color:rgb(242,251,251)">Dear PDWG,</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">The discussion appears to have shifted from whether hierarchical AS-SET naming is useful to whether implementing it requires a binding policy. Those are separate questions.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">A number of responses suggest that because AFRINIC is a community-driven organisation, policy is the appropriate mechanism whenever the community wishes to guide implementation. Community participation is unquestionably important, but participation alone does not determine whether every operational matter should become a policy obligation.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">An operational process does not have to exclude the community. AFRINIC could publish the proposed implementation, invite comments, test the approach, document objective criteria, report the outcome, and provide a review mechanism where necessary. Such an approach preserves transparency and community oversight without automatically moving an implementation detail into the policy layer.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">This proposal concerns the naming of new AS-SET objects in the IRR. It does not establish rules for allocating or recovering Internet number resources. That distinction is important because it helps maintain a meaningful boundary between resource policy and operational implementation.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">The question therefore is not whether hierarchical naming is beneficial. It may well be. The relevant question is whether a binding policy is necessary to protect a clearly identified technical requirement, such as uniqueness, interoperability, registry integrity, security, or operational continuity.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">The examples raised from other RIRs are relevant because they demonstrate that similar technical outcomes have been achieved through operational mechanisms. That does not mean AFRINIC must adopt the same approach, but it does mean the policy route requires its own technical justification.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">If the same technical outcome can be achieved through a transparent, community-reviewed operational implementation, then introducing a binding policy should require demonstrating what additional technical objective only policy can achieve.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">It also seems important not to reverse the burden of proof. Where a proposal introduces a new mandatory rule, it is reasonable to ask its proponents to explain why that rule is technically necessary and why a less intrusive operational approach would be insufficient.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">The central question therefore remains:</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">What technical requirement cannot be met through an open, community-reviewed operational implementation, but can only be achieved through binding policy?</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">Answering that question would help clarify whether this proposal belongs within the policy framework or whether it is more appropriately addressed as an operational matter.</p><p style="font-size:12.8px;background-color:rgb(242,251,251)">Kind regards,</p></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Tue, 21 Jul 2026, 10:55 , <<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. Re: Writing tools (Sami Ait Ali Oulahcen)<br>
2. Re: [Last Call] Draft Policy Proposal - Hierarchical Names<br>
for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02) (Noah)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 21 Jul 2026 09:45:47 +0100 (WEST)<br>
From: Sami Ait Ali Oulahcen <<a href="mailto:sami@marwan.ma" target="_blank" rel="noreferrer">sami@marwan.ma</a>><br>
To: "rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] Writing tools<br>
Message-ID: <<a href="mailto:1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma" target="_blank" rel="noreferrer">1809710664.2684.1784623547091.JavaMail.zimbra@marwan.ma</a>><br>
Content-Type: text/plain; charset=utf-8<br>
<br>
Hi all,<br>
<br>
It's been really difficult to follow the list this past 2/3 days. And I imagine I'm not alone.<br>
I fully agree on moderating the AI madness. Otherwise, it'll dissuade many folks from following/participating.<br>
<br>
Regards,<br>
Sami<br>
<br>
----- Original Message -----<br>
From: "Mike Silber" <<a href="mailto:silber.mike@gmail.com" target="_blank" rel="noreferrer">silber.mike@gmail.com</a>><br>
To: "rpd >> AfriNIC Resource Policy" <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Sent: Monday, July 20, 2026 4:40:55 PM<br>
Subject: Re: [rpd] Writing tools<br>
<br>
A useful discussion - thank you<br>
<br>
On Mon, Jul 20, 2026 at 5:17?PM Mike Burns via RPD <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>> wrote:<br>
<br>
> Hi Rob,<br>
><br>
> Yes, the language is a clear tell of AI usage, but flowery language alone<br>
> is not swamping the list.<br>
<br>
I don't want to hijack the AS-SET discussion, so thank you for the new<br>
> subject line.<br>
><br>
<br>
Agreed<br>
<br>
><br>
> Now, sometimes and unfortunately, I can use vague and flowery language<br>
> myself, so I would advise you to treat the AI stuff like the human stuff.<br>
> Ignore it if it's too vague or flowery to serve as a good argument, and<br>
> you have clearly laid out the two arguments in your last two lines.<br>
> Hopefully the list will show judgement and treat clear and concise<br>
> arguments better than vague ones.<br>
> And then the AI posts, if they want to be successful, will avoid the<br>
> purple prose.<br>
><br>
<br>
I think it goes beyond flowery language.<br>
<br>
I am concerned that this is a precedent for AI generated DDoS attacks on<br>
the PDP and I do think we should have some light touch guidelines. I<br>
suspect that one of the reasons for the AI-slop flood is not just to try<br>
convince anyone of the value or legitimacy of their views but rather to<br>
overwhelm and frustrate other participants and cause them to withdraw from<br>
participation.<br>
<br>
Accordingly, I suggest we don't simply leave this to the co-chairs to<br>
determine on a case by case basis, but rather set some guidelines under<br>
which measures can be taken to avoid AI DDoS.<br>
<br>
Anyway - just my ZAR0,02 which is not worth much<br>
<br>
Regards<br>
<br>
Mike S<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>
<br>
Message: 2<br>
Date: Tue, 21 Jul 2026 11:54:49 +0300<br>
From: Noah <<a href="mailto:noah@neo.co.tz" target="_blank" rel="noreferrer">noah@neo.co.tz</a>><br>
To: Jordi Palet Martinez <<a href="mailto:jordi.palet@consulintel.es" target="_blank" rel="noreferrer">jordi.palet@consulintel.es</a>><br>
Cc: rpd <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
Subject: Re: [rpd] [Last Call] Draft Policy Proposal - Hierarchical<br>
Names for New AS-SETs (AFPUB-2026-ASN-001-DRAFT02)<br>
Message-ID:<br>
<CAEqgTWY4AXZFDWqsHgdkMC0HHguDckAP4bJDY+uagmuzXBeX=<a href="mailto:Q@mail.gmail.com" target="_blank" rel="noreferrer">Q@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"<br>
<br>
Jordi,<br>
<br>
Also to add that the technical community's support for the proposal is<br>
based on our recognition, that, hierarchical naming improves attribution of<br>
the objects.<br>
<br>
The issue of validating the members inside the as-set is a separate one and<br>
I for one dont dispute that changamoto. Its also a fact that the specific,<br>
documented problem of unattributable as-set names in multi-source irr<br>
environments remains real. It needs a fix.<br>
<br>
Technical communities across the five Registy's are chosing to close that<br>
gap at creation time are doing so based on experienced operational<br>
incidents, some through policy (apnic) and others through techops<br>
implementation.<br>
<br>
The policy route will suffice at afrinic...<br>
<br>
Ahsante sana<br>
Noah<br>
<br>
On Tue, 21 Jul 2026, 12:17?am jordi.palet--- via RPD, <<a href="mailto:rpd@afrinic.net" target="_blank" rel="noreferrer">rpd@afrinic.net</a>><br>
wrote:<br>
<br>
> Hi Kone,<br>
><br>
> And what is the relevance of that?<br>
><br>
> If you have a good understanding about all the RIRs, you will know that<br>
> each RIR has their own ways to do things. In many senses they act very<br>
> similarly and in general we end up with very similarly policies, but not<br>
> always. Some RIRs have decided that some aspects are operational and don?t<br>
> need a policy proposal.<br>
><br>
> However, despite that, the community is on top of the RIR, and the<br>
> community sometimes, may decide that they prefer a policy if the RIR hasn?t<br>
> been proactive in advance in any specific topic, or even if the RIR was<br>
> proactive, the community may prefer to speed up things, or to show the way<br>
> the community prefers.<br>
><br>
> For example, if AFRINIC has any specific operational aspect already in<br>
> place, and the community prefer to manage that in a different way, the<br>
> community may opt either for suggesting the RIR to modify that operational<br>
> aspect or to do actually enforce it by means of a policy proposal.<br>
><br>
> I think is important to know, by personal experience, how the other 4 RIRs<br>
> work before stating something that is not correct, because if you don?t<br>
> work in all the RIRs for many years, it will be difficult for you to know<br>
> the past and I?m sure IA will not be able to be precise as well.<br>
><br>
> Regards,<br>
> Jordi<br>
><br>
> @jordipalet<br>
><br>
> El 20 jul 2026, a las 22:34, Kone <<a href="mailto:bakenon.kone@sancfis.net" target="_blank" rel="noreferrer">bakenon.kone@sancfis.net</a>> escribi?:<br>
><br>
> Hello Seun,<br>
> You may have misread my earlier mail. I clearly stated that LACNIC, RIPE<br>
> NCC, and ARIN do not require policy to enforce hierarchical AS?SET naming.<br>
><br>
> To help close the ongoing discussions, I believe addressing the questions<br>
> I raised would bring clarity:<br>
> * LACNIC enforces hierarchical AS?SET naming operationally, as part of<br>
> their IRR design from inception.<br>
> * RIPE NCC handles IRR changes through their Numbered Work Items (NWI)<br>
> process, not through policy.<br>
> * ARIN uses the ACSP (Consultation and Suggestion Process) for IRR<br>
> operational matters, again without policy.<br>
><br>
><br>
> These examples show that other RIRs (except APNIC) treat AS?SET naming as<br>
> an operational IRR matter, not a policy obligation.<br>
><br>
> This is why I asked whether AFRINIC could address this operationally<br>
> rather than through policy, and why Last Call discussions would benefit<br>
> from clear answers to these points.<br>
><br>
> Thanks.<br>
> ---<br>
> Kone<br>
><br>
><br>
><br>
> Le dim. 19 juil. 2026 ? 00:21, Seun Ojedeji <<a href="mailto:seun.ojedeji@gmail.com" target="_blank" rel="noreferrer">seun.ojedeji@gmail.com</a>> a<br>
> ?crit :<br>
><br>
>> Hello Bakenon,<br>
>><br>
>> Do refer to the proposal as it references URL to other RIR's policies for<br>
>> thiis:<br>
>><br>
>> <a href="https://www.afrinic.net/afpub-2026-asn-001-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-asn-001-draft02.html</a><br>
>><br>
>> Regards<br>
>><br>
>> ----<br>
>> Sent from my mobile<br>
>> kindly excuse typos<br>
>><br>
>> On Sat, 18 Jul 2026, 6:34?pm Bakenon KONE, <<a href="mailto:bakenon.kone@sancfis.net" target="_blank" rel="noreferrer">bakenon.kone@sancfis.net</a>><br>
>> wrote:<br>
>><br>
>>> Dear PDWG,<br>
>>><br>
>>> I have been following the discussions on the hierarchical AS?SET naming<br>
>>> scheme and would like clarification on a few points:<br>
>>><br>
>>> 1. Could this matter be addressed operationally, as is done in ARIN,<br>
>>> LACNIC, and RIPE NCC, without requiring policy changes?<br>
>>><br>
>>> 2. If yes, why are we taking the policy route? Is it because AFRINIC<br>
>>> currently lacks a defined process for handling operational issues that<br>
>>> affect IRR services?<br>
>>><br>
>>> 3. Given that the hierarchical naming scheme is already supported and<br>
>>> currently exists within the IRR, this proposal represents an enforcement<br>
>>> change rather than the introduction of a new technical standard. Why is a<br>
>>> formal policy required to change an operational enforcement setting, rather<br>
>>> than a community-vetted technical implementation plan?"<br>
>>><br>
>>> Thank you.<br>
>>> ---<br>
>>> Kone<br>
>>><br>
>>><br>
>>><br>
>>> Le jeu. 16 juil. 2026 ? 22:10, Hytham El-Nakhal <<a href="mailto:hytham@tra.gov.eg" target="_blank" rel="noreferrer">hytham@tra.gov.eg</a>> a<br>
>>> ?crit :<br>
>>><br>
>>>> Dear PDWG,<br>
>>>><br>
>>>><br>
>>>> The Policy Development Working Group (PDWG) Chairs have initiated a<br>
>>>> Last Call for this proposal, following rough consensus at the AFRINIC-37<br>
>>>> Public Policy Meeting held in hybrid format in Nairobi, Kenya on 24 June<br>
>>>> 2026.<br>
>>>><br>
>>>> * Proposal Name: Hierarchical Names for New AS-SETs<br>
>>>><br>
>>>> * Proposal ID: AFPUB-2026-ASN-001-DRAFT02<br>
>>>><br>
>>>> * Proposal URL:<br>
>>>> <a href="https://www.afrinic.net/afpub-2026-asn-001-draft02.html" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/afpub-2026-asn-001-draft02.html</a><br>
>>>><br>
>>>> Last Call closes on: July 31, 2026, at 23:59 UTC.<br>
>>>><br>
>>>><br>
>>>> Please note the staff observation regarding implementation constraints:<br>
>>>> due to the current prioritization of the MyAFRINIC v2 deployment, physical<br>
>>>> database implementation of this policy will be scheduled once the MyAFRINIC<br>
>>>> v2 deployment is concluded.<br>
>>>><br>
>>>><br>
>>>> As always, we kindly request that all participants adhere to the<br>
>>>> AFRINIC Code of Conduct<<a href="https://www.afrinic.net/code" rel="noreferrer noreferrer" target="_blank">https://www.afrinic.net/code</a>> to maintain a<br>
>>>> respectful and professional environment on the mailing list.<br>
>>>><br>
>>>><br>
>>>> Kind regards,<br>
>>>><br>
>>>><br>
>>>> Haitham el Nakhal<br>
>>>><br>
>>>> AFRINIC PDWG Co-Chair<br>
>>>><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>
>>>><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>
> 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>
> IPv4 is over<br>
> Are you ready for the new Internet ?<br>
> <a href="http://www.theipv6company.com" rel="noreferrer noreferrer" target="_blank">http://www.theipv6company.com</a><br>
> The IPv6 Company<br>
><br>
> This electronic message contains information which may be privileged or<br>
> confidential. The information is intended to be for the exclusive use of<br>
> the individual(s) named above and further non-explicilty authorized<br>
> disclosure, copying, distribution or use of the contents of this<br>
> information, even if partially, including attached files, is strictly<br>
> prohibited and will be considered a criminal offense. If you are not the<br>
> intended recipient be aware that any disclosure, copying, distribution or<br>
> use of the contents of this information, even if partially, including<br>
> attached files, is strictly prohibited, will be considered a criminal<br>
> offense, so you must reply to the original sender to inform about this<br>
> communication and delete it.<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>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://lists.afrinic.net/pipermail/rpd/attachments/20260721/68d4d480/attachment.html" rel="noreferrer noreferrer" target="_blank">https://lists.afrinic.net/pipermail/rpd/attachments/20260721/68d4d480/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 117<br>
*************************************<br>
</blockquote></div>